SUID, SGID, and Sticky Bits are powerful special permissions you can set for executables and directories on Linux. We’ll share the benefits—and potential pitfalls—of using them.
They’re Already in Use
Building security into a multiuser operating system presents several quandaries. Take the (seemingly) basic concept of passwords, for example. They all have to be stored so each time someone logs in, the system can compare the password he types to the stored copy. Obviously, as passwords are the keys to the kingdom, they must be safeguarded.
On Linux, stored passwords are protected in two ways: they’re encrypted, and only someone with
root privileges can access the file that contains the passwords. That might sound fine, but it presents a quandary: If only people with
root privileges can access stored passwords, how do those who don’t have that access change their passwords?
Elevating Your Status
Usually, Linux commands and programs run with the same set of permissions as the person who launches the program. When
root runs the
passwd command to change a password, it runs with
root’s permissions. That means the
passwd command can freely access the stored passwords in the
What would be ideal is a scheme in which anyone on the system could launch the
passwd program, but have the
passwd program retain
root’s elevated privileges. This would empower anyone to change her own password.
The above scenario is precisely what the Set User ID bit (
SUID) does. It runs programs and commands with the permissions of the file owner, rather than the permissions of the person who launches the program.
You’re Elevating the Program’s Status
There is another quandary, though. The person has to be prevented from meddling with anyone else’s password. Linux incorporates the
SUID scheme which allows it to run applications with a set of temporarily borrowed permissions—but that’s only half of the security story.
The control mechanism that prevents someone from working with another person’s password is contained within the
passwd program, not the operating system and the SUID scheme.
Programs that run with elevated privileges can pose security risks if they’re not created with a “security by design” mindset. That means security is the first thing you consider, and then you build on that. Don’t write your program, and then try to give it a coat of security afterward.
The biggest advantage of open source software is you can look at the source code yourself or refer to trusted peer-reviews of it. In the source code for the
passwd program, there are checks, so you can see whether the person running the program is
root. Different capabilities are allowed if someone is
root (or someone using
This is the code that detects whether someone is
The following is an example in which that’s taken into account. Because
root can change any password, the program doesn’t have to bother with the checks it usually performs to see which passwords the person has permission change. So, for
root, it skips those checks and exits the checking function.
With the core Linux commands and utilities, you can be confident they’ve got security baked into them and that the code has been reviewed many times. Of course, there’s always the threat of as-yet-unknown exploits. However, patches or updates are quick to appear to counter any newly identified vulnerabilities.
It’s third-party software—especially any that isn’t open-source—you need to be extremely careful about using
SUID with. We’re not saying don’t do it, but, if you do, you want to make sure it won’t expose your system to risk. You don’t want to elevate the privileges of a program that isn’t going to correctly self-govern itself and the person running it.
Linux Commands That Use SUID
The following are a few of the Linux commands that use the SUID bit to give the command elevated privileges when run 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 the filenames are highlighted in red, which indicates the SUID bit is set.
The permissions on a file or directory are usually represented by three groups of three characters: rwx. These stand for read, write and execute. If the letters are present, that permission has been granted. If a hyphen (
-) instead of a letter is present, though, that permission hasn’t been given.
There are three groups of these permissions (from left to right): those for the owner of the file, for members of the file’s group, and for others. When the
SUID bit is set on a file, an “s” represents the owner’s execute permission.
SUID bit is set on a file that doesn’t have executable capabilities, an uppercase “S” denotes this.
We’ll take a look at an example. Regular user
dave types the
passwd command prompts
dave for his new password. We can use the
ps command to see the details of running processes.
grep in a different terminal window and look for the
passwd process. We’ll also use the
-e (every process) and
-f (full-format) options with
We type the following command:
ps -e -f | grep passwd
Two lines are reported, the second of which is the
grep process looking for commands with the string “passwd” in them. It’s the first line that interests us, though, because that’s the one for the
We can see the
passwd process runs the same as it would if
root had launched it.
Setting the SUID Bit
It’s easy to change the
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 created a small program called
htg. It’s in the root directory of the
dave user, and it doesn’t have the
SUID bit set. When it’s executed, it displays the real and effective user IDs (UID).
The real UID belongs to the person who launched the program. The effective ID is the account the program is behaving as though it had been launched by.
We type the following:
ls -lh htg
When we run the local copy of the program, we see the real and effective IDs are both set to
dave. So, it’s behaving just as a normal program should.
Let’s copy it to the
/usr/local/bin directory so others can use it.
We type the following, using
chmod to set the
SUID bit, and then check that it’s been 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’ll run it again, but this time we’ll run the copy in the
dave launched the program, the effective ID is set to the
root user. So, if
mary launches 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 permissions of the root user.
The SGID Bit
The Set Group ID (
SGID) bit is very similar to the
SUID bit. When the
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 file’s group, rather than the permissions of the person who launched it.
We tweaked our
htg program so it shows the effective group, too. We’ll change the group of the
htg program to be user
mary‘s default group,
mary. We’ll also use the
g+s symbolic modes with
chown to remove the
SUID bit and set the
To do so, we type 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 the
SGID bit denoted by the “s” in the group permissions. Also, note the group is set to
mary and the file name is now highlighted in yellow.
Before we run the program, let’s establish which groups
mary belong to. We’ll use the
id command with the
-G (groups) option, to print all group IDs. Then, we’ll run the
htg program as
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
htg program is 1001. So, although it was launched by
dave, it’s running with the permissions of the members in the
mary group. It’s the same as if
dave had joined the
Let’s apply the
SGID bit to a directory. First, we’ll create a directory called “work,” and then change its group to “geek.” We’ll then set the
SGID bit on the directory.
When we use
ls to check the settings of the directory, we’ll also use the
-d (directory) option so we see the details of the directory, not its contents.
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 will affect any items created within the
We type 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 type 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.”
The Sticky Bit
The sticky bit gets its name from its historical purpose. When set on an executable, it flagged to the operating system that the text portions of the executable should be held in swap, making their re-use faster. On Linux, the sticky bit only affects a directory—setting it on a file wouldn’t make sense.
When you set the sticky bit on a directory, people can only delete files that belong to them within that directory. They can’t delete files that belong to someone else, no matter which combination of file permissions are set on the files.
This allows you to create a directory that everyone—and the processes they launch—can use as shared file storage. The files are protected because, again, no one can delete anyone else’s files.
Let’s create a directory called “shared.” We’ll use the
o+t symbolic mode with
chmod to set the sticky bit on that directory. We’ll then look at the permissions on that directory, as well as the
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 highlighted in blue.
/var/tmp folders are two examples of directories that have all the file permissions set for the owner, group, and others (that’s why they’re highlighted in green). They’re used as shared locations for temporary files.
With those permissions, anyone should, theoretically, be able to do anything. However, the sticky bit overrides them, and no one can delete a file that doesn’t belong to him.
The following is a quick checklist of what we covered above for future reference:
SUIDonly works on files.
- You can apply
SGIDto directories and files.
- You can only apply the sticky bit to directories.
- If the “
g“, or “
t” indicators appear in uppercase, the executable bit (
x) hasn’t been set.