14

Having worked with Linux for years, and finding myself with some free time, I decided to revisit some basics. So I re-read the stuff about permissions (without checking source code), and its special cases for folders, and came up with a new (to me at least...) way of thinking about folder permissions (for a specific user/group/others): I imagine a folder as a table with two columns, like so:

filename | inode    
foo      | 111  
bar      | 222

The read permission means you can read (and list) the left column of the table, the write permission corresponds to adding and removing entries to the table, and the execute permission corresponds to being able to translate from file name to inode; i.e. you can access the contents of the folder.

I did some experiments, and the results are all consistent with this "worldview" of mine, but one conclusion seems inescapable: that a folder with permissions d-w-------, is totally useless. Elaborating: you can't list its contents, you can't read any files you know exist inside (because you can't translate names into inodes), you can't remove or rename or add files, because again that would imply translation, and you can't even add hardlinks (because, I surmise, that would mean adding a name as well as an inode number, which means you would know both, which in turn, again surmising, violates the purpose of unsetting execution permission). And of course, if there are files inside one such folder, then you can't delete that folder either, because you can't delete its contents.

So... I would like to ask two questions:

  1. Is this analogy of mine correct, or is it a big blunder?
  2. Irrespective of the previous answer, is there any situation where having a folder with permissions as described is appropriate?
Improve this question
7
  • 3
    It may be that not every combination is useful. For example, in English we have words, these words are made up of letters, not all combinations make up valid words. e.g. aoeuidhtns
    – ctrl-alt-delor
    Aug 8, 2014 at 9:33
  • In this way couldn't you e.g. create a file? You request to the filesystem space and inode, and after you write name and inode in your directory table. You should have only the problem to have 2 files with the same name but different inode in the same directory...
    – Hastur
    Aug 8, 2014 at 10:55
  • @Hastur: I thought so too, but after mkdir foo ; chmod 200 foo ; touch foo/bar I get touch: cannot touch ‘foo/bar’: Permission denied. This happens even if foo/bar already exists. I'm testing in bash (Arch Linux).
    – wmnorth
    Aug 8, 2014 at 11:01
  • My fault I was thinking you were rewriting from source code the system... we cannot have two files with the same name in the same directory so it is logic it is forbidden to give the possibility to create it.
    – Hastur
    Aug 8, 2014 at 14:05
  • Yes, it is useless. The inode resolution requires "x" and "r" as well, thus on directories even a single "rw" is useless.
    – peterh
    Aug 8, 2014 at 16:11

2 Answers 2

Reset to default
6

Your understanding is pretty much correct. A better way to think of the execute permission is that it allows you to do things with a file or directory name in the directory (other than just reading the name itself). Most of those things involve translating the name to an inode, but it also includes creating new names and removing existing names.

Write permission to the directory without execute is therefore pretty useless, since there's nothing you can actually write if you can't access the files within it.

Improve this answer
2
  1. Is this analogy of mine correct, or is it a big blunder?

I think it's correct, you need wx permission to be able to write to a folder.

  1. Irrespective of the previous answer, is there any situation where having a folder with permissions as described is appropriate?

You may have a process that writes information in a folder and another one consumes it but you need to prevent the writer from reading other information stored in that place.

The situation described before is useful in automatic speed enforcement units. This units must go through a verification process where the state officer must minimize adulteration possibilities. Some automatic speed enforcement units have an external sd memory card where the system stores violation registers. But it could also store a "magic" config file that illegally changes the behavior of the verified unit. So the process that writes the violation register must not be able to read anything from sd memory card.

Here It is an example, first with write only, an then how to make it work with wx:

Mount a device 

root@leon:/media# mount -o umask=527,uid=enforcer,gid=ftp /dev/sdb1 /media/pen/
root@leon:/media# ls /media/pen/ -la
total 44
d-w-r-x--- 10 enforcer ftp  4096 Dec 31  1969 .
drwxr-xr-x  8 root     root 4096 Oct 17 16:14 ..

then with user enforcer try to write a new file

enforcer@leon:~$ touch /media/pen/hola
touch: cannot touch ‘/media/pen/hola’: Permission denied

unmount and remount with wx

root@leon:/media# umount /dev/sdb1
root@leon:/media# mount -o umask=427,uid=enforcer,gid=ftp /dev/sdb1 /media/pen/
root@leon:/home/jjorge# ls /media/pen/ -la
total 44
d-wxr-x--- 10 enforcer wim  4096 Dec 31  1969 .
drwxr-xr-x  8 root     root 4096 Oct 17 16:14 ..

try again

enforcer@leon:~$ touch /media/pen/hola
enforcer@leon:~$ ls /media/pen/
ls: cannot open directory /media/pen/: Permission denied
enforcer@leon:~$ cat /media/pen/hola
cat: /media/pen/hola: Permission denied

ftp@leon:/home/jjorge$ ls /media/pen/ -la
total 44
d-wxr-x--- 10 enforcer ftp  4096 Oct 20 10:20 .
drwxr-xr-x  8 root     root 4096 Oct 17 16:14 ..
--wxr-x---  1 enforcer wim     0 Oct 20 10:20 hola

With this configuration you are now able to write

Improve this answer

You must log in to answer this question.

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