Why does chmod succeed on a file when the user does not have write permission on parent directory?

Question

I am trying to understand file/dir permissions in Linux. A user can list the files in a directory using

cd test
ls -l 

Even if the user issuing above commands does not have read, write or execute permission on any of the files inside the test directory, still he can list them because he/she has read permissions on the test directory.

Then why in the following scenario user B can change permissions of a file he owns but does not have write permissions of the parent directory?

User A, makes a test directory and gives other users ability to write in it:

mkdir test
chmod o+w test

User B, creates a file in test folder.

cd test
touch b.txt

User A removes write permission of others from the directory

chmod o-w test

User B, can successfully change permissions, even though permissions are part of directory and this user does not have write permission on the parent directory of the file he owns

chmod g-r b.txt

why does chmod not fail since the user cannot modify the directory which has the file information - permissions etc?

Answer 1

When you change a file's metadata (permissions, ownership, timestamps, …), you aren't changing the directory, you're changing the file's inode. This requires the x permission on the directory (to access the file), and ownership of the file (only the user who owns the file can change its permissions).

I think this is intuitive if you remember that files can have hard links in multiple directories. The directory contains a table that maps file names to inodes. If a file is linked under multiple names in multiple directories, that's still one inode with one set of permissions, ownership, etc., which shows that the file's metadata is in the inode, not in the directory.

Creating, renaming, moving or deleting a file involves modifying the directory, so it requires write permission on the directory.