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?

Answer 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.

Answer 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