Working with Users, Groups, and Permissions – Part V

Advanced Permissions:

  • Linux also has a set of advance permissions
  • These are not permissions you would set by default, but in some instances, they provide a useful addition
  • In this section, you’ll learn what the advanced permissions are and how to set them

Understanding Advanced Permissions:

  • There are 3 advanced permissions
  • The 1st of them is the “set user ID (SUID) permission”
  • On some very specific occasions, you may want to apply this permission to executable files
  • By default, a user who runs an executable file runs this file with their own permissions
  • For standard users, this normally means the use of the program is restricted
  • In some cases, however, the user needs special permissions for the execution of a certain task
  • Consider the situation where a user needs to change their password. . .To do this, the user needs to write the new password to the “/etc/shadow” file
  • This file is not writable for users who don’t have root permissions
  • The SUID permission offers a solution for this problem
  • On the “/usr/bin/passwd” utility, this permission is applied by default
  • So, when changing a password, the user temporarily has root permissions, which allow the user to write to the “/etc/shadow” file
  • You can see the SUID permission with: # ls –l …. as an “s” at the position where normally you would expect to see the “x” for the user permissions:
  • The SUID permission may look useful, and it is in rare cases; however, it is potentially dangerous as well
  • If applied incorrectly, you can give away root permissions by accident

In general: The SUID (or set user id) is a permission bit, that allows the users to exec a program with the permissions of its owner

  • The 2nd special permission is “ set group ID (SGID) ”
  • This permission has two effects:
  • If applied on an executable file, it gives the user who executes the file the permissions of the group owner of that file
  • SGID can accomplish more or less the same thing that SUID does; however, SGID is hardly ever used for this purpose
  • When applied to a directory, SGID may be used to set default group ownership on files and subdirectories created in that directory
  • By default, when a user creates a file, the user’s effective primary group is set as the group owner for that file
  • That’s not always very useful
  • Imagine a situation where users linda and lori work for the accounting department and both are members of the “group” account
  • By default, these users are members of the private group of which they are the only members
  • Both users, however, are also members of the accounting group but as a secondary group setting
  • The default situation is that when either of these users creates a file, the primary group becomes owner
  • However, if you create a shared group directory, say “/groups/account” and you apply the SGID permission to that directory and set the group “accounting” as the group owner for that directory, all files created in this directory and all of its subdirectories would also have group “accounting” as the default group owner
  • The SGID permission shows in the output of “# ls –l” as an “s” at the position where you would normally find the group execute permission
  • The 3rd of the special permissions is called “sticky bit”
  • Sticky bit permission is used to protect files against accidental deletion in an environment where multiple users have write permissions in the same directory
  • For that reason, it is applied as a default permission to the “/tmp” directory, and it can be useful on shared group directories as well
  • Without sticky bit, if a user can create files in a directory, the user can also delete files from that directory
  • In a shared group environment, this may be annoying
  • Imagine users “linda” and “lori” again. . .both of whom have write permissions to the the directory “/data/account” and who have these permissions because of their membership of the group “accounting”
  • That means that “linda” is capabile of deleting files that lori has created, and vice versa
  • When applying sticky bit, a user can delete files only if either of the following is true:
  • The user is owner of the file
  • The user is owner of the directory where the file exists
  • When using the command: # ls –l, you can see sticky bit as a “t” at the position where you would normally see the execute permission for others

Applying Advanced Permissions:

  • To apply SUID, SGID, and sticky bit, you can use the “chmod” command
  • SUID has numerical value of 4
  • SGID has numerical value of 2
  • Sticky bit has numerical value of 1
  • To apply these permissions, you need to add a four-digit argument to “chmod”, where the 1st digit refers to the special permissions
  • For example: # chmod2755 /somedir
  • Command would add the SGID permission to a directory and set “rwx” for user and “rx” for group and others
  • It is recommended to work in relative mode if any special permissions need to be applied
  • For SUID, use: # chmodu+s
  • For SGID, use: # chmodg+s
  • For sticky bit, use: # chmod +t, followed by the name of the file or the directory on which you want to set the permission
  • SEE Table Below: Working with SUID, SGID, and sticky bit

Exercise Time:

  • Working with Special Permissions