Linux File System Permissions – Special
In the previous two posts we looked at the basic permissions for Linux File System and the umask concept and how that works. In this post, we will look at special permissions for Linux File System. The basic permissions are great and we can do a lot with them but then there are times when you want to do more with file permissions specially in a multi-user environment where each user has access to the same folder. This is easily achieved in windows with NTFS permission but in Linux world we have the following three special permissions
- SUID – Set User Identification
- SGID – Set Group Identification
- Sticky Bit
|SUID||Run file as the owner||NONE|
|SGID||Run file as the group owner||Inherit group permission|
|Sticky Bit||NONE||Only allow owner to delete files inside the folder|
What the table is showing you is the effect of each option on file and/or folder. So, SUID is set on files not folders and what it does is that when a non-owner runs a file that has the SUID set, the file will always run with the permissions of the owner account. This is useful for things like changing user passwords. The utility used to change passwords on linux is called passwd and when you change your password, system makes changes to a file /etc/shadow but normal users don’t have access to this file so how would a normal user then change his/her password? The answer is SUID. The utility passwd has SUID bit set which means when a user types passwd and changes his/her password then the passwd will run as a root user and make changes to the /etc/shadow file. A non-root user can not directly make changes to /etc/shadow file. That raises a question. What if I use passwd and change the password of another user? Let’s try it
[anna@localhost ~]$ passwd john
passwd: Only root can specify a user name.
So, we know that you cannot specify a username with passwd as a basic user and you can only change your own password.
SGID on files does the same thing as SUID does for files. Any file with SGID set will run as the permission of the owner group. I think this is not commonly used by administrators but when you set SGID on folders, any file created within that folder will inherit group permissions set on the folder.
Sticky Bit ensures that a file within a folder can only be deleted by the Owner of the file. So, even if another user is a member of the same group as the owner of the file, that user can read/edit or execute depending on the group permissions but cannot delete the file. Remember that the owner of the group will still be able to delete any file.