I am trying to understand file/dir permissions in Linux. A user can list the files in a directory using cd testls -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 testchmod o+w testUser B, creates a file in test folder.cd testtouch b.txtUser A removes write permission of others from the directorychmod o-w testUser 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 ownschmod g-r b.txtwhy does chmod not fail since the user cannot modify the directory which has the file information - permissions etc?
Why does chmod succeed on a file when the user does not have write permission on parent directory?
files;permissions;directory;chmod;file metadata
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.