2

Say I have a directory with these permissions:

drwxrwx---

Inside this directory, a file with these permissions:

-rw-rw-rw-

Is the file readable/writable by everyone or not ?

If not, how secure is this access restriction?

What if a random user makes a link to my file inside his home directory? Could he access the file then?

Or could he access the file by guessing its inode number and using some system calls on inodes?

4

Yes, a file in a directory is only accessible to users who have the execute permission on the directory. It's like leaving jewelry in an unlocked drawer inside a locked house: the jewelry is under lock.

A random user cannot create a hard link to a file, only the owner file. If the file has multiple hard links, some of which are in a publicly accessible directory, then the file will be publicly accessible. But that has to be set up by the owner of the file.

Anyone can create symbolic links that happen to point to a file, but that doesn't allow them to access the file. Symbolic links do not bypass permissions.

If the directory is world-executable at some point and there are processes that have the file or a parent directory opened at the time you restrict the permissions on the directory, then those processes still have the file open afterwards. However if they close it (or move out to another directory) they won't be able to reopen it (or change directory back in). Similarly, a setuid or setgid process may open the file or change to the directory, then drop its permissions. All of this requires the cooperation of the file or directory owner.

There is no way to open a file via its inode. The fact that this would allow to bypass restrictive permissions such as this case is the main reason why this feature doesn't exist.

1

My guesses:

  • No one but the owner and group of the directory should be able to enter it in normal conditions, given the permission mask drwxrwx---.
  • An user wanting to hard-link to your file would need to guess its inode first, and for that he would use the system call "lstat" ("man 2 lstat"), which needs read access and wouldn't work in this case.
  • Guessing the inode number and using some system calls to link to it wouldn't work either, AFAIK. The system call to link to a file is "link" ("man 2 link"), and it works with paths, not with inode numbers. I guess you could go to a lower level and try to use the syscalls that "link" itself uses, but for that you'd need root access. And if you've got root access, the question is moot.

BTW, thanks for the question. It's related to one of the subjects I'm studying nowadays :-)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.