25

Why is it that you cannot access a file when you only know its inode, without searching for a file that links to that inode? A hard link to the file contains nothing but a name and a number telling you where to find the inode with all the real information about the file. I was surprised when I was told that there was no usermode way to use the inode number directly to open a file.

This seems like such a harmless and useful capability for the system to provide. Why is it not provided?

Null Set
  • 5,374
  • 24
  • 37
  • 2
    What is the use case of doing this? – user562374 Jan 05 '11 at 16:57
  • @user The question was inspired by this question. http://stackoverflow.com/questions/4605851/how-to-get-directory-name-by-inode-value-in-c I could also see it being used to pass a file to another user who has access to the file but doesnt have access to my directory structure. – Null Set Jan 05 '11 at 17:08
  • 5
    That's exactly the reason it's not allowed. If accessing files by inode number were permitted, you could simply try every inode number and bypass all directory permissions. – R.. GitHub STOP HELPING ICE Mar 12 '11 at 05:56
  • A use case would be to be certain to open the same file like somebody else who has it already open. A filename on UNIXs might be pointing to some other file meanwhile. –  Jan 30 '14 at 19:23
  • 1
    But if you have the filename you can get an inode - that use-case is still open to you. So you can compare the inodes and verify -samefile if you have that. But you cannot manipulate directly by inode alone. I think that's the gist I'm getting here anyway. – mikeserv Apr 06 '14 at 04:54

5 Answers5

19

Security reasons -- to access a file you need permission on the file AS WELL AS permission to search all the directories from the root needed to get at the file. If you could access a file by inode, you could bypass the checks on the containing directories.

This allows you to create a file that can be accessed by a set of users (or a set of groups) and not anyone else -- create directories that are only accessable by the the users (one dir per user), and then hard-link the file into all of those directories -- the file itself is accessable by anyone, but can only actually be accessed by someone who has search permissions on one of the directories it is linked into.

Chris Dodd
  • 119,907
  • 13
  • 134
  • 226
18

Some Operating Systems do have that facility. For example, OS X needs it to support the Carbon File Manager, and on Linux you can use debugfs. Of course, you can do it on any UNIX from the command-line via find -inum, but the real reason you can't access files by inode is that it isn't particularly useful. It does kindof circumvent file permissions, because if there's a file you can read in a folder you can't read or execute, then opening the inode lets you discover it.

The reason it isn't very useful is that you need to find an inode number via a *stat() call, at which point you already have the filename (or an open fd)...or you need to guess the inum.

  • 4
    Ah, but if you close the file and then want to re-open it later you would not have to stat it. – johnnycrash Jun 30 '11 at 22:51
  • @johnnycrash what does that get you? You can't be talking about any meaningful performance gain as you're about to use a file on some really slow storage medium. –  Mar 25 '12 at 10:15
  • 3
    @johnnycrash you wouldn't be sure that you'd be opening the same file actually: the same inode could have been destroyed and re-used by the filesystem for a new file, and you wouldn't have any way to check if that happened. – pqnet Aug 06 '14 at 06:14
  • 1
    It is important when your filesystem grows large. When you have 8 TB disks with 150 million files that are iterated it can speed up things a few hundert percents. – Lothar Apr 21 '16 at 20:04
4

Btrfs does have an ioctl for that (BTRFS_IOC_INO_PATHS added in this patch), however it does no attempt to check permissions along the path, and is simply reserved to root.

Gabriel
  • 1,262
  • 12
  • 12
4

In response to your comment: To "pass a file", you can use fd passing over AF_LOCAL sockets by means of SCM_RIGHTS (see man 7 unix).

user502515
  • 4,346
  • 24
  • 20
2

Surely if you've already looked up a file via a path, you shouldn't have to do it again and again?

stat(f,&s); i=open(f,O_MODE);

involves two trawls through a directory structure. This wastes CPU cycles with unnecessary string operations. Yes, the well-designed file system cache will hide most of this inefficiency from a casual end-user, but repeating work for no reason is ugly if not plain silly.

Matthias Braun
  • 32,039
  • 22
  • 142
  • 171
John Allsup
  • 1,072
  • 8
  • 9
  • You store the inode in the database and avoid a few access cycles, this are dozends of milliseconds not nanoseconds for string operations. 1000 times faster, especially if you sort the inode numbers. – Lothar Apr 21 '16 at 20:06
  • This is giving me some ideas. The @Lothar comment is right on spot: if you bypass use of names through filesystem, you basically have to implement some equivalent using a database. If you are opening the same files over an over and want the only real issue may be to avoid parsing millions on files in the same directory again and again... solution ? just hardlink to these files in a directory containing much less files. This will avoid most lost CPU cycles, basically doing nearly the same as accessing by inode. – kriss Jan 25 '18 at 10:50