SUID, SGID, and Sticky Bits are powerful special permissions that you can set on executable files and directories on Linux. We’ll share the benefits – and potential pitfalls – of using them.
They are already in use
Integrating security into a multi-user operating system poses several problems. Take the (seemingly) basic concept of passwords, e.g. example. They all need to be saved so that every time someone logs in, the system can compare the password they entered with the saved copy. Of course, since passwords are the keys to the kingdom, they need to be protected.
On Linux, saved passwords are protected in two ways: They are encrypted and only someone with
root Permissions can access the file that contains the passwords. That may sound good, but it is a quandary: if only people with
root Permissions can access saved passwords. How can those who do not have this access change their passwords?
Raise your status
Typically, Linux commands and programs run with the same permissions as the person who starts the program. When
root runs the
passwd command change a password, it runs with
root‘s permissions. That means the
passwd Command can freely access the passwords saved in the
Ideally, a scheme where everyone on the system can use the
passwd Program, but they have
passwd Keep the program
root‘s increased privileges. This would give everyone the opportunity to change their own password.
The above scenario is exactly what the Set User ID bit (
SUID) does. It executes programs and commands with the permissions of the file owner and not the permissions of the person who starts the program.
They increase the status of the program
There is another dilemma, however. The person must be prevented from interfering with someone else’s password. Linux includes the
SUID Scheme that allows applications to run with a range of temporarily borrowed permissions – but that’s only half the story of security.
The control mechanism that prevents someone from working with someone else’s password is in the
passwd Program, not the operating system and the SUID scheme.
Programs that are executed with elevated privileges can pose security risks if they are not created with a “security by design” mentality. That said, safety is the first thing you consider and then build on it. Don’t write your program and then try to put a security jacket around it.
The biggest advantage of open source software is You can take a look at the source code for yourself or refer to trusted peer reviews. In the source code for the
passwd There are checks in the program so you can see if the person running the program
root. Other skills are allowed if someone is
root (or someone used
this is the code that recognizes if someone is
The following is a example in which this is taken into account. because
root can change any password, the program doesn’t have to mess with the checks it normally does to see which passwords the person is allowed to change. So for
root, it skips these tests and ends the test function.
With basic Linux commands and utilities, you can be sure that they are safe and that the code has been verified many times. Of course, there is still a risk of unknown exploits. However, patches or updates appear quickly in order to counter newly identified vulnerabilities.
It is third party software – especially those that are not open source – you need to be extremely careful when using them
SUID with. We’re not saying you shouldn’t, but when you do you want to make sure your system is not exposed to any risk. You don’t want to elevate the privileges of a program that doesn’t properly manage itself and the person who runs it.
Linux commands that use SUID
Below are some of the Linux commands that use the SUID bit to give the command elevated privileges when run by a normal user:
ls -l /bin/su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/umount
ls -l /usr/bin/passwd
Notice that the filenames are highlighted in red, indicating that the SUID bit is set.
Permissions for a file or directory are usually represented by three groups of three characters: rwx. These stand for reading, writing and executing. If the letters are there, permission has been given. If a hyphen (
-) is present in place of a letter, however, permission has not been granted.
There are three groups of these permissions (from left to right): those for the owner of the file, for members of the filegroup, and for others. If that
SUID If the bit is set for a file, an “s” stands for the owner’s authorization to execute.
SUID Bit is set on a file that has no executable capabilities, a capital “S” indicates this.
We look at one example. Normal user
dave Guys who
dave for his new password. We can use that
ps command to see the details of running processes.
grep in another terminal window and look for the
passwd Process. We will too
-e (any process) and
-f (Full format) options with
We enter the following command:
ps -e -f | grep passwd
Two lines are reported, the second of which is the
grep Look for the process for commands with the string “passwd”. However, it is the first line that interests us because that is the one for them
We can see that
passwd The process is the same as when
root had launched it.
Set the SUID bit
It’s easy to change
SUID bit with
u+s symbolic mode sets the
SUID bit and the
u-s symbolic mode clears the
To illustrate some of the concepts of the SUID bit, we have a little program called. created
htg. It is located in the root directory of the
dave User, and it doesn’t have the
SUID Bit set. When it is run it will show the real and effective user ids (UID).
The real one UID belongs to the person who started the program. The effective ID is the account with which the program behaves as if it was started.
We enter the following:
ls -lh htg
When we run the local copy of the program, we see that the real and effective ID are both set to
dave. So it behaves as a normal program should.
Let’s copy it to the
/usr/local/bin Directory so others can use it.
We enter and use the following
chmod who adjust
SUID bit, then check that it has been set:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
The program is copied and the SUID bit is set. We’ll run it again, but this time we’re running the copy in the
dave the program has been started, the effective ID is transferred to the
root User. So if
mary the program starts, the same thing happens as shown below:
The real ID is
mary, and the effective ID is
root. The program runs with the privileges of the root user.
How to use the chmod command on Linux
The SGID bit
The set group ID (
SGID) Bit is very similar to that
SUID Bit. If that
SGID Bit is set on 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 filegroup, not the permissions of the person who started it.
We optimized ours
htg Program so that it also indicates the effective group. We’re changing the group of
htg Program to the user
mary‘s standard group,
mary. We will too
g+s symbolic modes with
chown to remove the
SUID Bit and set the
To do this, we enter the following:
sudo chown root:mary /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg
You can see that
SGID Bit identified by the “s” in the group authorizations. Also note that the group is set to
mary and the file name is now highlighted in yellow.
Before we run the program, let’s determine which groups
mary belong. We’ll use that
id Command with the
-G (Group) option, to print out all group IDs. Then we run them
htg Program as
We enter the following commands:
id -G dave
id -G mary
The ID of the default group for
mary is 1001, and the effective group of
htg Program is 1001. So even though it was started by
dave, it runs with the permissions of the members in
mary Group. It is the same as when
dave had joined that
Let’s apply that
SGID Bit in a directory. First we create a directory called “work” and then change its group to “geek”. We then set the
SGID Bit in the directory.
When we use
ls To check the settings of the directory, we also use the
-d (Directory) Option so that we can see the details of the directory, not its contents.
We enter the following commands:
sudo mkdir work
sudo chown dave:geek work
sudo chmod g+s work
ls -lh -d work
SGID Bit and group “Geek” are set. These affect all elements within the. were created
We enter the following to enter the
work Directory, create a directory called “demo” and check its properties:
ls -lh -d demo
SGID bit and “geek” group are automatically applied to the “demo” directory.
Let’s enter the following to create a file with the
touch Command and check its properties:
ls -lh useful.sh
The group of the new file is automatically set to “Geek”.
How to use the chown command on Linux
The sticky bit
The sticky bit gets its name from its historical purpose. When it is set for an executable, it will tell the operating system that the text parts of the executable should be kept in swap in order to expedite its reuse. On Linux, the sticky bit only affects one directory – setting it on a file would not make sense.
When you set the sticky bit on a directory, users can only delete files that they own within that directory. You cannot delete files that belong to another person, regardless of the combination of file permissions set on the files.
This allows you to create a directory that anyone – and the processes they start – can use as shared file storage. The files are protected because again nobody can delete other people’s files.
Let’s create a directory called “shared”. We’ll use that
o+t symbolic mode with
chmod to set the sticky bit in this directory. We’ll then see the permissions for that directory as well as the
We enter the following commands:
sudo chmod o+t shared
ls -lh -d shared
ls -lh -d /tmp
ls -lh -d /var/tmp
When the sticky bit is set, the executable bit of the “other” set of file permissions is set to “t”. The file name is also highlighted in blue.
/var/tmp Folders are two examples of directories where all file permissions are set for owner, group, and others (that’s why they’re highlighted in green). They are used as shared storage locations for temporary files.
With these permissions, anyone should, in theory, be able to do anything. However, the sticky bit overwrites them, and no one can delete a file that they don’t own.
Below is a quick checklist for what we covered above for reference later:
SUIDonly works with files.
- You can apply
SGIDto directories and files.
- You can only apply the sticky bit to directories.
- If the “
g“, or “
t”Displays appear in capital letters, the executable bit (
x) is not set.