Semantics of Linux O_PATH file descriptors?

Question

Linux 2.6.39 introduces the O_PATH open mode, which (roughly speaking) does not really open the file at all (i.e. does not create a description of the open file), but simply gives the file descriptor that the descriptor is an unopened target. Its main use is as an argument to *at functions ( openat , etc.). And it seems appropriate as an implementation of the POSIX 2008 O_SEARCH , which Linux was previously absent. However, I could not find good documentation on the exact semantics of O_PATH . I have a few specific questions:

• What operations are possible with Linux O_PATH file descriptors? (Only *at functions?)
• Is O_PATH ever useful with non-directories?
• How is the file descriptor attached to the object of the underlying file system, and what happens if it is moved, deleted, etc.? Does the file descriptor O_PATH as a link that prevents the release of the object when the last connection is disconnected? Etc.

Answer 1

File descriptors obtained using open(directory, O_PATH | O_DIRECTORY) are useful not only for functions ...at() , but also for fchdir() (since kernel version 3.2.23, I think).

There is also a recent patch for the new syscall, fbind() , which will allow the use of very long Unix domain socket names. The socket file is first created with mknod(path, mode | S_IFSOCK, (dev_t)0) , then opened with open(file, O_PATH) . The file descriptor thus obtained and the Unix domain socket descriptor are passed to fbind() to associate the socket with the path name. Whether this will be included in the Linux kernel has not yet been noticed - although, even if it is, it will be years before it can be relied on that it is universally available. (As a workaround for Unix domain socket names that are too long, this would be more likely, rather.)

I would say that O_PATH is useful only for directories; file usage may be found in the future. Besides the possibility of future fbind() or similar future system calls, I don’t know how to use file descriptors for files opened with O_PATH . Even fstatvfs() will not work, at least on the 3.5.0 kernel.

On Linux, inodes (file contents and metadata) are freed only when the last open file descriptor is closed. When you delete (detach) a file, you only delete the file name associated with the inode. Thus, there are two separate filesystem objects associated with the file descriptor: the name used to open the object, and the base inode. The name is used only to resolve the path, i.e. When open() is called (or equivalent). All data and metadata are in the inode.

File descriptors obtained using O_PATH behave (at least on the 3.5.0 kernel), just like regular file descriptors. Moving and renaming components of the name or name used to open the handle. (The descriptor remains valid because it refers to the inode, and the file name object was used only during path resolution. Keeping the descriptor open will maintain allocated resources, even if the descriptor has been opened by O_PATH .)