logic behind deleting files where user does not have right to write

Question

When I create a file with no write permissions in my home directory:

$ umask 777; touch testfile
$ ls -ln testfile
---------- 1 1000 1000 0 2014-03-21 16:52 testfile
$

..then I'm still easily able to remove that file:

$ rm -fv testfile
removed `testfile'
$ 

When I create a file with no write permissions to a directory where I don't have write permissions, then I'm not able to remove such file:

$ ls -lnd /var/
drwxr-xr-x 14 0 0 4096 2014-03-21 17:04 /var/
$ ls -ln /var/testfile
---------- 1 1000 1000 0 2014-03-21 17:04 /var/testfile
$ rm -vf /var/testfile 
rm: cannot remove `/var/testfile': Permission denied
$ 

Am I correct that write permissions are inherited from parent directory? Is it true for read and execute permissions as well?

Answer 1

No, permissions are not inherited this way. The reason is slightly different: removing a file doesn't count as writing the file - it counts as writing the directory! This is why you can erase a file even when you have no rights over its content.

Deleting an entire file is considered fundamentally different from editing it. The most thing you can do to a file where you don't have write permission on the directory is to empty its contents, but you can't get rid of the directory entry,

Answer 2

The ability to delete a file has nothing to do with the actual permissions on the file. It's the permissions of the directory that contain the file that govern this.

Example

$ whoami
saml

$ ll -d adir/
drwxrwxr-x. 2 samtest samtest 60 Mar 21 14:35 adir/

$ rm adir/afile 
rm: remove write-protected regular empty file ‘adir/afile’? y
rm: cannot remove ‘adir/afile’: Permission denied

However if I change the permissions such that user saml has write access to adir.

$ sudo chmod o+w adir/

And now if this user attempts to delete the afile:

$ rm adir/afile 
rm: remove write-protected regular empty file ‘adir/afile’? y

$ ll adir/
total 0

So just remember that the ability to read/write/execute a file belong to the file itself through its attributes. However the ability to delete a file from a directory is controlled by the permissions of the directory containing the file.

Answer 3

Permissions are not inherited. Once you enter the directory, the files can have any permissions or ownership. For instance, you can have complete permissions over files two folders deep, but you may not have a permission to enter the directory. Writing permission on a directory means you can modify the list of files (move/delete/create file), but modification of file contents is something different. Read permission on a directory allows you to read the list of files (running ls). The execute permission of a directory means you can cd into it.

For instance, if your permissions on a directory are 'wx', you can create or remove files, enter directories in it, but you cannot list its contents (meaning that tab completion in bash won't work). However, a subfolder contents can be listed if its permission says so.

A bit of an exception is the sticky bit, which when set, restricts what you can do with files in a directory with this bit set. If it is set (chmod 1??? where ??? is the conventional permission, such as 755), the files cannot be deleted by a person that is not the owner of the file or the containing directory, even if he has a write permission. That's useful for some uses (for instance /tmp/ directory is usually marked this way - everyone can write in it, but can't touch stuff that isn't his).

Answer 4

File permissions in Unix are not inherited from the parent directory (with the exception of the sticky bit.) There is distinction between the permissions of the directory itself and the permissions of the files within the directory. What you have described is the ability to make changes to the directory (write permission on the directory), not the file. If you have Unix write permission on a directory, either via the group write or the owner write bit, then this gives you the ability to add and remove contents from that directory: you may add or remove subdirectories or files, regardless of what the permissions on the file are.

Answer 5

There is a reason why directories are called "directories": because they work exactly like directories in real life. If you want to remove a person from the phone directory, then you only need access to the phone directory, not to the person. (This is different from a "folder", if you want to remove a document from a folder, you need access to both the folder and the document.)