, why are so weird for directories?

Read perms let you list the filenames in the directory but nothing else (e.g.. not contents of files nor metadata like size or file owners).

Write perms let you add/delete/rename files in that directory, but only if exec perms are also present.

Exec perms let you read or write to files that already exist in a directory, but not list the names nor change the names. Hope you already know the filename you're after.

... WHY??

@JordiGH Why not?

@stsp Hahahaha

C'mon, there must be a reason. It must be one of those little bugs that grew up to be a big and strong independent feature, like dotfiles being hidden.

@stsp I'm guessing it's due to some peculiarity of how inodes were first implemented.

Also, please tell me that you had to remember how directory permissions work, because I always think I know how and then get confused by weird directory modes like 0300, 0200, or 0600.

@JordiGH I did not remember their meaning in detail, no.

But what do you think is wrong with the scheme you described? What would you change if you could?

@stsp I think:

Read: List names in that directory and read file contents, including metadata. This also allows cd'ing into that directory.

Write: Modify names in that directory and file contents, including metadata.

Exec: Allow executing files from that directory, or just do nothing.

@JordiGH @stsp Your proposal would basically mean: Managing permissions per directory, so no granularity. You can change modes recursively (chmod -R) or set the sticky bit, which applies all modes set to the directory to newly created files in that directory (if I'm not mistaking, never used that).

@kay @stsp You are mistaken, but I don't fault you, this shit is needlessly confusing. 🙂

The sticky bit just makes it so that nobody but the user, the owner of the directory or root can delete a file. It's pretty much only useful for shared directories like /tmp so you can't go around deleting other users' files despite several users being able to write files in there.

@kay @stsp As to my proposal, that would just be for directories. Files themselves would keep their own permissions.

Mind you, Unix permissions are all sorts of wacky and not really useful for anything beyond the most simple basic tasks. It's kind of pointless to fix them.

I just wanted to point out that the current state of directory permissions is wacky and I want to know how did it come to this.

@JordiGH Thanks a lot for the explanation! So I was thinking the wrong thing for quite a while 😂

@kay I'll probably forget again how Unix permissions work and will have to look them up. They're really weird.

@JordiGH @kay I suspect things are they way they are because under the hood directories are just files and perms apply to their inode and not things their entries point to.

@JordiGH The exec part is because there are executables that everyone should be able to execute, but they don't need to see what is available. You want almost everyone to be able to use what is in /bin, but you don't want anything else above their home folder to be accessible to them. It is easier to keep track of what is going on if you say 'everyone gets exec permissions on /bin' and leave it at that.

I don't know about the other two.

@inmysocks Hm, but how can the shell search your PATH if there are no read permissions for part of it? The shell can't list names, ohhhh, right, why list when you can just grab the requested executable and append it to each part of the PATH in turn to see if it would work.

Okay, but why do exec permissions also let you write to files if you already know their names?

@JordiGH I am not sure about the second part. One thing to remember is that system processes have unlimited access for the most part, it is only your commands that are limited. So if you execute a file and the file writes to something it may not be using your permissions to determine if it is possible.

If exec permissions let you write to files directly than I have no idea, that doesn't really make sense.

@inmysocks You also need the file's write permissions to be set, but the directory's exec permissions are also required to write to that file.

I am thinking of trying to figure out how inodes were originally implemented to see if I can find the underlying reason.

@JordiGH yeah, that is weird. Let us know what you find out!

@JordiGH The directory permissions might make more sense if you think of a directory as holding a list of files. You need read permission to read the list, write permission to modify the list and access permission to access the list of files.

See this website to see if this helps explains directory permissions [ hackinglinuxexposed.com/articl ].

@sohkamyung And exec permissions? Why are they required for everything else that's actually going to be of use? And why do write permissions require exec, what's the point of that?

I feel like this will only make sense once I understand more about how the filesystem is implemented.

@JordiGH @sohkamyung The regular execute permission isn't meaningful for directories, so that bit was repurposed as "permission to access paths below this directory." One use case is letting users access their own home directory without letting them get the full list of dirs under /home by setting only the exec bit. It may seem weird, but it makes some sense in the context of early Unix systems.

@federicomena "The first rule is that whenever we want to open any type of file by name, we must have execute permission in each directory mentioned in the name, including the current directory, if it is implied."

Why is that?

And why do we require to open files to rename/delete/create them?

@federicomena "To delete an existing file, we need write permission and execute permission in the directory containing the file. We do not need read permission or write permission for the file itself."

C'mon, this is weird. Who came up with these rules?

I don't think anyone came up with them.

I think they must be a consequence of some implementation choice of the 1970s.

@JordiGH "Note that read permission for a directory and execute permission for a directory mean different
things. Read permission lets us read the directory, obtaining a list of all the filenames in the
directory. Execute permission lets us pass through the directory when it is a component of a
pathname that we are trying to access. (We need to search the directory to look for a specific
filename.)"

+r means "can you read the list of files", and +x means "can you access the files".

@JordiGH e.g. you can have a +r-x directory, and you'll be able to list its contents, but not open files in it.

Or you can have a -r+x directory, and you *can't* list its contents, but if you know the names of files inside it, you can open them just fine. This is an old trick for kinda-sorta-secret directories.

@federicomena So why can't I create a new name in that directory with +w-x?

It seems that if w is just about the names in that directory, I shouldn't need to access any files in that directory to add a new name to that directory.

@JordiGH Because with -x you can't access the directory entry that would be created for the new file.

I'm having a hard time looking in the kernel sources for just where this is implemented. Probably fs/namei.c:generic_permission(), but that calls into the capabilities code and I have no idea about that.

@JordiGH relatedly, if you have r-x on a directory but no w, you can modify a file in it, but not rename the file or create a new one.

@federicomena Of course, you don't need +r either, just -r-w+x lets you modify files and read them too.

But +r-w-x lets you read the names in that directory.

I can see how some of these cases might be useful, but overall this feels a lot like the PHP hammer.

@JordiGH maybe a combination of

* small installations with only a few trusted people, back in the 1970s
* having only a few bits, permissions make sense
* "let's reuse this bit because directories are special anyway"
* no capabilities, extra security foo developed yet?

@JordiGH
Because of reasons. 🤔

A Mastodon instance for maths people. The kind of people who make $\pi z^2 \times a$ jokes.

Use $ and $ for inline LaTeX, and $ and $ for display mode.