How permission inheritance really works?
 

Hello all,

I used to think that i knew reasonably well linux permissions but... i have made a little test and i cannot understand the results

I make a new directory let's say "test" with user backup and group users

drwxr-xr-x 2 backup users 4.0K Aug 28 13:56 test

and inside it i create with root user test.txt

-rw-r--r-- 1 root root 0 Aug 28 13:58 test.txt

My surprise came when i found out that backup user can erase the file, is some kind of inheritance that i don't fully understand?? How can a non-root user can erase a root file?

Some extra info,

uid=0(root) gid=0(root) groups=0(root)

uid=1000(backup) gid=100(users) groups=100(users)

How this works and how i can see thsi new permissions reflected?

Thanks for the help!

deleting a file means you modify the directory only (removes an entry), you do not need any rights to that file.

This is why the sticky bit exists (today, in the earlier days of Unix it meant something else)..
When applied to a directory only the owner of the directory (in your case, backup), the owner of the file and the root user can unlink (delete) the file..

A correct set of permissions that would disallow file deletion would be So that everybody in the users group can write to the directory, but only the owner of the file or root user can delete it..

P.S. My recommendation would be to create a backup group (with the user backup) and set the backup directory ownership to that group... This way only backup can write there but it can't delete root's file.. You then can also disable global read and execute for the directory so that normal users don't have access to that data..

Thanks for the answer, must admit i'm still a bit confused, so when any user create a dir he's automatically the "root" on that dir and can erase any file he wants of any user? I thought that root files were immune to any deletion except for root of course.

So the fact that backup cannot erase files in /bin is because the directory was created with root permissions, not because of the perms on the files inside was defined on a certain way? and i assume that the creator of a dir will determine the permissions of ALL files on it? no need for chmod and chown it all depends on WHO create the directory.

I had no clue that linux worked that way, and i'm sure a lot of other people don't know it as well, glad i found out

Thanks for the help.

The directory permissions affect (besides the obvious reading and entering the directory) creating and deleting of the files found in that directory... The file permissions control whether the user can actually read or write to that file (or execute it)..

To better understand, think of the directory as a normal file with a list in it... If you can write the file, you can modify the list.. Thus add or remove files from that directory... The
The root user is special just because he can do anything regardless of permissions.. That doesn't mean that it's files are immune to normal permissions.. But yes, that's why most system directories have root:root set as the owner... That ensures that users can't add or delete files from that directory..

No.. Reading, writing or executing are separate permissions on a file basis..

Take a look at my directory test and it's contents:
In it, only root can create or delete files.. However, everyone can read or write to test.txt (they just can't delete the file, even if they can write to it)... Because the directory is owned by root and only the user write flag is set, even smokey (the file owner) can't delete the file 'test.txt'.... So you see, adding a file and deleting a file are handled at directory level, while reading a file and writing a file handled at file level..


P.S. There are even Access Control Lists in newer linuxes that people don't know about... For more informations check

Just a historical note on the "sticky" bit.

On the UNIX implementations (PDP-11 based) the sticky bit was used to identify executables that could be loaded when executed (there were some reorganizations,swap allocations and such). The file would be configured for execution in swap space, then copied into memory to be run. When the executable of a "sticky" file exited, the swap space would not be deallocated. The next time the application was run, it would load immediately from the swap (much faster), and not need the preloading and swap allocation. Thus, the executable was "sticky" and remain in swap for faster startup.

When BSD (and the larger UNIX systems after the 16 bit PDP-11), the sticky bit was no longer used - still defined, just not supported any more. BSD then reused the bit to mark /tmp as a restricted directory and would disable the ability for just any user to delete files (/tmp up to this time had been access mode 777). With the sticky bit added to the directory only the owner of files in the directory could delete the file.

Thank you very much Smokey, your explanation has been extremely helpful, was a little explanation but does help me improve a LOT my Linux skills :)

Have a great day!