0

This question already has an answer here:

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.

marked as duplicate by Toby Speight, ilkkachu, elbarna, Archemar, msp9011 Mar 20 at 13:28

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 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 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 at 10:21
4

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
  • But won't that allow the user to delete /tmp/parent? – Not an artist Mar 19 at 10:49
  • @Notanartist not without the write permission: rm -r /tmp/parent/ - rm: cannot remove '/tmp/parent/': Operation not permitted – Mr Shunz Mar 19 at 10:50
  • Thanks! That detail was escaping me. – Not an artist Mar 19 at 10:51
0

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.

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