Why can't read the contents of a directory?

Question

All filenames mentioned here are directories.

The permissions of /media/disk are 0744 (drwxr--r--). The permissions of /media/disk/directory are 0755 (drwxr-xr-x). I do not own these directories in anyway.

Why can I ls /media/disk, but can't ls /media/disk/directory? My guess is that ls needs run access to /media/disk, but this would be stupid because if I have read access to a file (i.e. if r is set), then I should be able to read the file.

In addition to the question above, if I'm correct in saying that the issue is due to lack of run access, I want to ask why what I said is stupid, isn't.

System information:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.2 LTS"

I don't think the proposed duplicate explains why this feature isn't stupid.

The use of rude language in the question was deliberate. I want to display my ignorance to get the help I need to understand this. — Not an artist, Mar 19 '19 at 10:12
I don't think the proposed duplicate explains why this feature isn't stupid. I find it rather idiotic to have to have access to a whole branch in order to access a single leaf. Seems like an invitation for security vulnerabilities (not that I would know). — Not an artist, Mar 19 '19 at 10:21
Related: Execute vs Read bit. How do directory permissions in Linux work? — ilkkachu, Mar 19 '19 at 20:39

score 5 · Accepted Answer · edited Mar 24 '19 at 12:13

5

Your /media/disk directory lacks the execute bit for group and "others".

This means (IMHO in a somewhat confusing way) that you can successfully read from the directory (as the read bit is set) and list its contents, while you cannot act on it nor enter it (via cd), and this includes listing its children's content as long the permission mask is 744.

If you want to access some specific subdirectory(-ies) without giving access to the whole tree, then it's a simple matter of removing read access but setting the execute bit:

$ su
# mkdir -p /tmp/parent/child
# chmod 711 /tmp/parent/
# chmod 755 /tmp/parent/child/
# touch /tmp/parent/child/test
# exit
$ ls /tmp/parent/
ls: cannot open directory '/tmp/parent/': Permission denied
$ cd /tmp/parent/
$ pwd
/tmp/parent
$ ls
ls: cannot open directory '.': Permission denied
$ ls child/
test

edited Mar 24 '19 at 12:13

Jeff Schaller

67,283
35
116
255

answered Mar 19 '19 at 10:17

Daniele Santi

4,137
2
30
30

But won't that allow the user to delete /tmp/parent? – Not an artist Mar 19 '19 at 10:49
@Notanartist not without the write permission: rm -r /tmp/parent/ - rm: cannot remove '/tmp/parent/': Operation not permitted – Daniele Santi Mar 19 '19 at 10:50
Thanks! That detail was escaping me. – Not an artist Mar 19 '19 at 10:51

score 1 · Answer 2 · answered Mar 19 '19 at 20:44

Stupidity is very much opinion-based, but consider that requiring the "execute" rights to all directories on the path means that access to a whole subtree can be denied by denying access to the root directory of that subtree. "Executing" a directory doesn't seem to make much sense, so the x bit might be better called "access" in the case of directories.

In other words, by setting the permissions of /home/$USER to 700 (i.e. rwx------) we can be sure that no other user an access the files of $USER even if they or some program they use accidentally creates files with more liberal permissions within their home directory. There's only one place to check, instead of each and every file.

Why can't read the contents of a directory?

2 Answers2