Why do you need execute permission on the parent directory to rename a file

Question

On Linux/Unix file-systems, I understand the reason why you need the execute permission on the parent folder to read or write a file: the execute permission gives you access to the inode on the file, and without that, you can never reach the content of the file.

However for renaming a file (actually, even deleting), you just need to change the name of the file in the list, which shouldn't require to have access to the inode. So why is the execute bit required for renaming a file, write permissions should be enough?

This doesn't seem symetric with read access: with r-- permissions, you can do ls on the directory and access the list of filenames in that directory. You don't need execute because you are not accessing the inodes. Similarly, with -w-, you should be able to change the list of filenames (you don't need to access the inodes either), but you can't, why?

Solution 1

The meaning of execute permission for a directory is the ability to look up file names inside that directory. Of course, successfully looking up a file name produces a reference to an inode number, but the execute permission has nothing to do with inodes per se.

Without execute permission on the directory, you can't stat, open, rename, delete, or descend into subdirectories inside that directory. The only thing you can do is see the list of which filenames exist, and then only if you have read permission (and read but not execute is a strange set of permissions to have for a directory).

Consider if you have rw- on a directory. You know that filename foo exists inside this directory. In order to delete it you need to look it up, and you even need access to the inode (to decrement its link count). For that matter, you need access to the inode in order to tell if it's a directory or not (because if it's a directory, unlink should fail and rmdir should succeed, and the reverse if it's not a directory). But you can't look it up.

Solution 2

The execute bit allows the affected user to enter it and access and change file and directory attributes and directories inside. permission to execute other filesystem linux commands may need to be "executed" on sub-directories and files is determined by "execute bit". Not to be confused with executing an executable file, it means you have given "executive decision-making" privvies to edit the links to inode file numbers or metadata associated with filenames and symbolic links.

Variations of features include Execute with write disabled. meaning you can rename a file but not edit the contents. Or write enabled but execute disabled visa versa.

"Each disk drive contains some number of file systems. A file system consists of a number of cylinder groups. Each cylinder group has inodes and data.

 A file system is described by its super-block, which in turn describes
 the cylinder groups.  The super-block is critical data and is replicated
 in each cylinder group to protect against catastrophic loss.  This is
 done at file system creation time and the critical super-block data does
 not change, so the copies need not be referenced further unless disaster
 strikes.

 Addresses stored in inodes are capable of addressing fragments of
 `blocks'. File system blocks of at most size MAXBSIZE can be optionally
 broken into 2, 4, or 8 pieces, each of which is addressable; these pieces
 may be DEV_BSIZE, or some multiple of a DEV_BSIZE unit."

Other interesting details; http://linux.about.com/library/cmd/blcmdl2_stat.htm

" If you have execute (but not write) permission on a directory AND you have write permission on a file living within, you cannot delete the file (because it involves removing it from the list). However, you can erase its contents e.g. if it's a text file you can use vi to open it and delete everything. The file will still be there, but it will be empty." ...Baldrick

stat -f "%Sp -> owner=%SHp group=%SMp other=%SLp" to display ACL stats

Comments

[Flavien]

I know that, but it doesn't answer my particular question. To rephrase: I can do ls if I have r--. Why can't I do mv if I have -w-? It should work the same, given neither of them require access to the inodes.

[Flavien]

I know what I can do, and what I can't. That's not my question, my question is why. I don't need to lookup any filename to rename a file. I just change a name to another name, I don't need to know what that name resolves to.

[Tony Stewart EE75]

think of writing or erasing contents as a delegated privvie with "w" attribute bit but deletion of filename as an executive decision with "exec" bit.

[Celada]

I tried to emphasize the nature of the "lookup" ability in my answer as an explanation for why. Another way to say it: the rename system call takes two pathnames as arguments. It looks up both. x is required to do that. But in the end, the best answer to "why" is "because POSIX defines it that way".

[Flavien]

It sort of make sense that for delete, you need to decrement the link count, therefore you need x to access the inode. For rename, I don't see why access to the inodes is needed.

[Ajedi32]

So technically you could delete a file or directory with just rw-? The way the answer is written now it sounds like if you had a (probably malicious) utility that simply unlinked files/directories without updating their link count or trying to check what kind of directory entry they are, then you could remove directory entries without needing the x bit.

[Celada]

@Ajedi32, no, you really do need the x permission. A malicious utility cannot skip those steps that require looking up and decrementing the link count because the POSIX kernel does not offer a system call that skips those steps. POSIX only offers unlink() (for files) and rmdir() (for directories) and those system calls both do all the right things with looking up and link counts.