SUID, SGID and Sticky Bits are powerful special permissions that you can set for executable files and folders on Linux. We share the benefits ̵
They are already in use.
Building security into a multi-user operating system has several problems. Take, for example, the (apparent) basic concept of passwords. They must all be saved so that every time someone logs in, the system can compare the password that they type with the saved copy. Since passwords are the keys of the kingdom, they must of course be protected.
Under Linux, saved passwords are protected in two ways: they are encrypted and only someone with
root has access to the file containing the passwords. That may sound good, but it poses a dilemma: if only people with
root have access to saved passwords, how can those who don't have access change their passwords?
Increase your status  Usually, Linux commands and programs are executed with the same set of permissions as the person who starts the program. When
root executes the command
passwd to change a password, it is executed with the permissions of
root . That means that the command
passwd has free access to the saved passwords in the file
/ etc / shadow .
What would be ideal is a scheme in which everyone on the system maintains the
passwd program, but lets the
passwd program retain the elevated rights of
root . This would allow anyone to change her own password.
The above scenario is exactly what the Set User ID bit (
SUID ) does. It executes programs & commands with the permissions of the file owner, rather than the permissions of the person starting the program.
You are increasing the status of the program.
However, there is another problem. The person must be prevented from interfering with someone else's password. Linux includes the
SUID scheme that allows it to run applications with a number of temporarily borrowed permissions – but that's only half the security story.
The operating mechanism that prevents someone from working with another person's password is contained in the program
passwd not the operating system and the SUID scheme.
Programs that run with elevated privileges can present security risks if they are not created with a "security by design" spirit. That means that security is the first thing you consider, and then you build on it. Do not write your program and then try to give it a layer of security.
The biggest advantage of open source software is that you can look at the source code yourself or refer to trusted peer reviews. The source code of the program
passwd contains checks so that you can see if the person who runs the program is
root . Various options are allowed if someone
is root (or someone who uses
This is the code that detects whether someone is
The following is an example that has been taken into account. Because
root can change any password, the program does not have to deal with the checks it usually performs to see which passwords the person with permission has changed. So for
root it skips those checks and leaves the checking function.
With the Linux core commands and utilities, you can be confident that they have security embedded and that the code has been revised many times. Of course there is always the threat of unknown exploits. However, patches or updates appear quickly to fix newly identified vulnerabilities.
It is third-party software – especially non-source software – you must be extremely careful when using
SUID with. We don't say you shouldn't do it, but if you do, you want to make sure it doesn't expose your system to risks. You do not want to increase the rights of a program that will not control itself and the person running it correctly.
Linux commands that use SUID
The following are some Linux commands that use the SUID bit to give the command elevated privileges when executed by a regular user:
ls -l / bin / su
ls -l / bin / ping
ls -l / bin / mount
ls -l / bin / umount
ls -l / usr / bin / passwd
Note that the file names are highlighted in red, indicating that the SUID bit is set.
The permissions for a file or folder are usually represented by three groups of three characters: rwx. These stand for reading, writing and execution. If the letters are present, permission has been granted. However, if there is a hyphen (
- ) instead of a letter, that permission is not given.
There are three groups of these permissions (from left to right): those for the owner of the file, for members of the file group, and for others. When the bit
SUID is set to a file, an "s" stands for the owner's execution permission.
If the bit
SUID is set to a file that has no executable file capability, a capital letter "S" indicates this.
We will view an example. Regular user
dave types the command
passwd command prompts
dave for his new password. We can use the command
ps to view the details of active processes.
grep in another terminal window and search for the
passwd process. We will also use the options
-e (any process) and
-f (full format) with
We type the following command:
ps -e -f | grep passwd
Two lines are reported, the second is the
grep process looking for commands with the string "passwd" in it. However, it is the first rule that interests us, because that is the one for the
We can see that the
passwd process executes the process the same as it would be if
root had launched it.
Setting the SUID bit
It is easy to change the
SUID bit with
chmod . The symbolic mode
u + s sets the bit
SUID and the symbolic mode
us erases the bit
To illustrate the concepts of the SUID bit, we have made a small program with the name
htg . It is in the user's root directory
dave and the bit
SUID is not set. When it is executed, the real and effective user ID & # 39; s (UID) is displayed.
The real UID is from the person who started the program. The effective ID is the account with which the program behaves as if it had been launched by.
We type the following:
ls -lh htg
When we run the local copy of the program, we see that the real and effective ID & Both are set to
dave . So it behaves exactly like a normal program should do.
Let's copy it to the
/ usr / local / bin folder for others to use.
We type the following using
chmod to set the bit
SUID and then check if it is set:
sudo cp htg / usr / local / bin
sudo chmod u + s / usr / local / bin / htg
ls -hl / usr / local / bin / htg
So the program is copied and the SUID bit is set. We will perform it again, but this time we will execute the copy in the folder
/ usr / local / bin :
dave launched the program, the effective ID is set to the user
root . So when
mary starts the program, the same thing happens as shown below:
The real ID is
mary and the effective ID is
root . The program runs with the root user's permissions.
RELATED: How to use the chmod command on Linux
The SGID Bit
The Set Group ID (
SGID ) bit seems very on the bit
SUID . When the bit
SGID is set to an executable file, the effective group is set to the group of the file. The process runs with the permissions of the members of the file group, rather than the permissions of the person who started it.
We have adjusted our program
htg to also show the effective group. We will change the program group
htg to user
mary 's default group,
mary . We also use the symbolic modes
g + s with
chown to remove the bit
SUID and to enter the
set SGID .
To do this, we type the following:
sudo chown root: mary / usr / local / bin / htg
sudo chmod us, g + s / usr / local / bin / htg
ls -lh / usr / local / bin / htg
You can see the bit
SGID that is indicated by the "s" in the group permissions. Also note that the group is set to
mary and the file name is now highlighted in yellow.
Before we execute the program, we will determine which groups
mary belong to. We use the
id command with the
-G (groups) option to print all group IDs. Then we run the program
We type the following commands:
id -G dave
id -G mary
The ID of the default group for
mary is 1001 and the effective group of the program
htg is 1001. So although it was launched by
dave it runs with the permissions of members in the
mary group. It is the same as if
dave had become a member of the
Let's apply the
SGID bit to a folder. First we create a folder with the name & # 39; work & # 39; and we change the group to & # 39; geek & # 39 ;. Next, we set the bit
SGID in the folder.
When we use
ls to check the settings of the folder, we also use the
-d (directory) option to see the details of the directory, not the content of it.
We type the following commands:
sudo mkdir work
sudo chown dave: geek work
sudo chmod g + s work
ls -lh -d work
SGID bit and "geek" group are set. These affect all items created in the
work folder .
We type the following to open the
work folder, create a folder named & # 39; demo & # 39; and check its properties:  cd-work
ls -lh -d demo
SGID bit and the "nerd" group are automatically applied to the "demo" directory.
Type the following to create a file with the command
touch and check its properties:
ls -lh useful.sh
The group of the new file is automatically set to & # 39; geek & # 39 ;.
RELATED: How to use the chown command on Linux
The Sticky Bit  The sticky bit owes its name to its historical purpose. When set to an executable file, it marked to the operating system that the text portions of the executable file had to be kept in swap, making the reuse faster. In Linux, the sticky bit only affects a folder – it would not make sense to place it in a file.
When you set the sticky bit in a folder, people can only delete files that belong to that folder. They cannot delete files that belong to someone else, regardless of which combination of file permissions are set on the files.
Allows you to create a folder that everyone – and the processes they start – to use as shared file storage. The files are protected, because again, nobody can delete someone else's files.
Let's create a folder with the name & # 39; shared & # 39 ;. We use the symbolic mode
o + t with
chmod to set the sticky bit in that folder. We look at the permissions in that folder, as well as the folders
/ tmp and
/ var / tmp .
We type the following commands:
sudo chmod o + t shared
ls -lh -d shared
ls -lh -d / tmp
ls -lh -d / var / tmp
 If the sticky bit is set, the executable bit of the "other" set of file permissions is set to "t". The file name is also marked in blue.
/ tmp and
/ var / tmp folders are two examples of folders with all file permissions set for the owner, group, and others (therefore, they are highlighted in green). They are used as shared locations for temporary files.
Anyone should be able to do anything in theory with those permissions. However, the sticky part replaces them, and no one can delete a file that is not his.
Below is a short checklist of what we have discussed above for future reference:
SUIDonly works on files.
- You can apply
SGIDto folders and files.
- You can only apply the sticky bit to folders.
- If the "
g" or "
t" indicators are shown in capital letters, the executable bit (
x) is not set.