6

I'm almost ashamed to admit that there is one thing I am still unsure about when it comes to file permissions.

Let's say I have a directory with 750 permission (drwxr.x...). Then I create some descendant files inside it with a rather common 644 permission (.rw.r..r..).

Can the files in that directory be read by any other user on the system (outside of their owner or group), and why? On the one hand, those files have a world readable bit, so that should indicate the file is readable by anybody. On the other hand, the ascendant directory is not world executable (nor readable) so as long as this prevents access to the directory's contents, the world readable bit on the files would be irrelevant. Is that definitively true or is there any way around this?

Now, I seem to regularly see instances where someone recommends a chmod -R o-rwx or something. On example is in Debian's Maildir directories created by postfix I believe - all files, not just the directory, have had world/group read removed. Is it really necessary to remove that world read bit from the files inside if the directory has no world access? I ask as I'm trying to plan how to set up /var/www on a server and have it not world-readable ie by other local users.

4 Answers 4

3

Yes, the files can be read, because they are world readable, but if the directory is not world readable, assuming the user is not in group owning the directory, the user would need another link to the file. e.g.:

cd directory
ln file /tmp

Now the user can access the file, but will have to do so using /tmp/file.

3
  • This was tested and confirmed in RHEL version 5. All the path trees to the file do not have to be accessible.
    – JeffG
    Mar 23, 2011 at 16:55
  • Thanks JeffG, I understand that with a soft link, they would be, but with a hard link or bind mount, they don't - so hard links and bind mounts can bypass this, but then a regular user wouldn't be able to create a hard link or bind mount into there anyway. Mar 24, 2011 at 4:02
  • @thomasrutter - AFAIK, you is correct. It's a fine point but it must be made, as some admins could make assumptions about file access based off the output of ls -l. The lesson for those admins is that when securing files, also pay attention to the link count in the output of ls. The GNU find utility also is helpful here when used with the -samefile option which helps to ferret out other hardlinks to the same file. I use find . -type f -links +1 -exec ls -l {} \; to find all files with multiple hard links or the -samefile option to find other links to the same file.
    – JeffG
    Mar 24, 2011 at 12:41
11

What you're asking has more to do with the way the virtual file system performs directory traversals. Due to the fact that everything on a Linux system is a file, this creates a peculiarity when dealing with directories. While they have an execute field, it is fairly meaningless to attempt to execute a directory. Moreover, in the ext2/3/4 file system, the data structure used bears little resemblance to "true" file. Instead, the permissions have slightly different meanings when applied to directories.

  • read -- The designate is permitted to print a listing of all directory entries
  • write -- The designate is permitted to create new directory entries
  • execute -- The designate is permitted to obtain the inode of directory entries

Understanding those distinctions, we can see that if a user's permissions on a specific directory are --x then we can determine that the user is capable permitted to attempt a file access but without actually being able to view the directory entry itself. Or more succinctly, as per coredump, "with --x you can't list the directory, but you can read the files inside it if the file permissions allow it."

Knowing all that, let's take the file /home/user/public/file as an example. Generally one should not open their home directory globally, however they want to offer files in 'public' globally. As such, you should set the permissions thusly:

  • /home -- 755
  • /home/user -- 711 (or possibly 751)
  • /home/user/public -- 755
3
  • 1
    What @packs means is that with --x you can't list the directory, but you can read the files inside it if the file permissions allow it.
    – coredump
    Mar 22, 2011 at 18:21
  • Excellent explanation. When I first started in unix I couldn't figure out why a directory I owned:group would not let me cd into it. Drove me nuts until I broke down and asked the sr guy. :)
    – egorgry
    Mar 22, 2011 at 19:45
  • Sorry packs, but I was trying to ask a question a bit different to the one you answered. I already suspect that the lack of read or execute permissions on the directory would prevent access to its files regardless of the file permissions. I was wondering if this was definitive or if there were still ways for other users to read the files. JeffG's answer helped me out, for example. I will try to clarify my question. Mar 22, 2011 at 23:42
2

No, they can't. All the path trees to the file has to be accessible too.

[it is possible to create directories that you can't see the contents of, but you can still read files in; ie a directory of hidden files, but not with 0750 permissions like in your example]

It is safer to create all the files and directories based on how you want it accessed though. If you move that file out of the existing directory to one with world-readability then suddenly your file that you're used to thinking of as "protected" won't be. If you have the file permissions to also be o-rwx then the file will be protected itself and won't rely on the directory to protect it.

0
1

This behavior is easy to test yourself.

$ mkdir foo
$ echo readable > foo/bar
$ ls -ld foo/
drwxr-xr-x 2 sciurus sciurus 4096 2011-03-22 1329 foo/
$ ls -l foo/
total 4
-rw-r--r-- 1 sciurus sciurus 9 2011-03-22 13:29 bar
$ cat foo/bar 
readable

$ chmod a-r foo
$ ls -ld foo/
d-wx--x--x 2 sciurus sciurus 4096 2011-03-22 1329 foo/
$ ls -l foo/
ls cannot open directory foo/: Permission denied
$ cat foo/bar 
readable

$ chmod a+r foo
$ chmod a-x foo
$ ls -ld foo/
drw-r--r-- 2 sciurus sciurus 4096 2011-03-22 1329 foo/
$ ls -l foo/
ls cannot access foo/bar: Permission denied
total 0
-????????? ? ? ? ?                ? bar
$ cat foo/bar 
cat foo/bar: Permission denied

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .