Permissions – Why Can rm Remove Read-Only Files?

filespermissionsreadonlyrm

If I create a file and then change its permissions to 444 (read-only), how come rm can remove it?

If I do this:

echo test > test.txt
chmod 444 test.txt
rm test.txt

…rm will ask if I want to remove the write-protected file test.txt. I would have expected that rm can not remove such a file and that I would have to do a chmod +w test.txt first. If I do rm -f test.txt then rm will remove the file without even asking, even though it's read-only.

Can anyone clarify? I'm using Ubuntu 12.04/bash.

Best Answer

All rm needs is write+execute permission on the parent directory. The permissions of the file itself are irrelevant.

Here's a reference which explains the permissions model more clearly than I ever could:

Any attempt to access a file's data requires read permission. Any attempt to modify a file's data requires write permission. Any attempt to execute a file (a program or a script) requires execute permission...

Because directories are not used in the same way as regular files, the permissions work slightly (but only slightly) differently. An attempt to list the files in a directory requires read permission for the directory, but not on the files within. An attempt to add a file to a directory, delete a file from a directory, or to rename a file, all require write permission for the directory, but (perhaps surprisingly) not for the files within. Execute permission doesn't apply to directories (a directory can't also be a program). But that permission bit is reused for directories for other purposes.

Execute permission is needed on a directory to be able to cd into it (that is, to make some directory your current working directory).

Execute is needed on a directory to access the "inode" information of the files within. You need this to search a directory to read the inodes of the files within. For this reason the execute permission on a directory is often called search permission instead.

Related Question