Linux File Permissions: Understanding setuid, setgid, and the Sticky Bit

Setuid, setgid, and the sticky bit can be tough for new and aspiring Linux admins to understand. It's easy enough to do a web search for the basic definitions:

• setuid: a bit that makes an executable run with the privileges of the owner of the file

• setgid: a bit that makes an executable run with the privileges of the group of the file

• sticky bit: a bit set on directories that allows only the owner or root can delete files and subdirectories

But those are oversimplifications and really comprehending the concepts well enough to pass an exam or use them effectively in the real world requires going a little deeper than that. Here, we're going to help you do just that. We'll review how setuid, setgid, and the sticky bit work and provide a list of common commands to help you get started. Having a strong understanding of these concepts is critical for passing any Linux certification.

Before diving into the world of umask, setuid, and setgid, we recommend reading up on file permissions, chmod, and chown. If you're already comfortable with chmod and chown, let's dive right in!

What are Setuid and Setgid?

Setuid and setgid are a way for users to run an executable with the permissions of the user (setuid) or group (setgid) who owns the file. For example, if you want a user to be able to perform a specific task that requires root/superuser privileges, but don't want to give them sudo or root access.

To understand why setuid and setgid are needed, let's start with how things work without them.

How Commands Work Without Setuid or Setgid

Normally, when a process on a Linux system is started it runs using the uid/gid of whatever user called it. This means it has the same privileges as the associated uid/gid would have. If neither your user, nor any of your real or effective groups have access, neither will you.

Let's walk through a simple example using the ls command. We have two subdirectories in our /topsecretfolder: secret1 and secret2. Both subdirectories are owned by root. The secret1 subdirectory allows read and execute permissions to everyone else. The secret2 subdirectory grants no privileges to everyone else.

cooluser@LAPTOP-5V55HON5:/topsecretfolder$ ls -l
total 8
drwxrwxr-x 2 root root 4096 Oct 18 19:34 secret1
drwxrwx— 2 root root 4096 Oct 18 19:31 secret2
cooluser@LAPTOP-5V55HON5:/topsecretfolder$

When we try to list files in /topsecretfolder/secret1, the system grants ls access based on the privileges tied to our "cooleruser" uid/gid.

cooluser@LAPTOP-5V55HON5:/topsecretfolder$ ls secret1
pepperNeggRecipe.txt
cooluser@LAPTOP-5V55HON5:/topsecretfolder2$

However, when we try the same thing on topsecretfolder/secret2, we get a permission denied message. That's because when running with our "cooluser" account's privileges, the system denies ls access to the secret2 subdirectory.

cooluser@LAPTOP-5V55HON5:/topsecretfolder$ ls secret2
ls: cannot open directory ‘secret2’: Permission denied
cooluser@LAPTOP-5V55HON5:/topsecretfolder3$

If we switch to the root (or use sudo) account, ls works fine on the secret2 subdirectory. This makes sense because now ls has the privileges associated with the root user.

root@LAPTOP-5V55HON5:/topsecretfolder# ls secret2
GiardinieraRecipe.txt
root@LAPTOP-5V55HON5:/topsecretfolder#

How Setuid/Setgid Works

We've seen how things work without setuid/setgid, and in most cases that's exactly how things should work. A user's privileges should dictate what the commands they execute can and cannot do.

However, in some cases, you may need a user to run a program with more privileges — usually root privileges — than they have by default. The textbook case for this is the passwd command that allows users to change their own password. Changing your password inherently requires changing the /etc/shadow file. However, only the root user has write access to /etc/shadow

cooluser@LAPTOP-5V55HON5:~$ ls -l /etc/shadow
-rw-r—– 1 root shadow 1824 Oct 18 19:49 /etc/shadow
cooluser@LAPTOP-5V55HON5:~$

Under normal circumstances, that suggests we'd need to be root or have sudo privileges to change our password. However, normal users can execute the passwd command to change their own password without sudo or root permissions.

cooluser@LAPTOP-5V55HON5:~$ passwd
Changing password for cooluser.
Current password:
New password:
Retype new password:
passwd: password updated successfully
cooluser@LAPTOP-5V55HON5:~1$

To understand why passwd seemingly grants root-level access but ls doesn't, let's take a look at the permissions on those two executables.

cooluser@LAPTOP-5V55HON5:~$ ls -l /bin/ls
-rwxr-xr-x 1 root root 142144 Sep  5  2019 /bin/ls
cooluser@LAPTOP-5V55HON5:~$ ls -l /bin/passwd
-rwsr-xr-x 1 root root 68208 May 28 01:37 /bin/passwd
cooluser@LAPTOP-5V55HON5:~$

Both executables are owned by the root user and group, and there is only one difference in the permissions. As you can see, the passwd executable has an "s" where you'd expect an "x" for the file owner's permissions. This "s" tells us the setuid bit is set.

Because the setuid bit is set, when we run the passwd command it is automatically executed as the owner of the file.  Since root is the owner, the password change and required edit to /etc/shadow work.

The setgid bit is also an "s", but in the execute position for the group that owns the file. For example, like what we see here on the wall executable in Ubuntu:

cooluser@LAPTOP-5V55HON5:~$ ls -l /usr/bin/wall
-rwxr-sr-x 1 root tty 35048 Apr  2  2020 /usr/bin/wall
cooluser@LAPTOP-5V55HON5:~$

Given those permissions, we know when we run the wall command, it will run with the privileges of the tty group.

What About the Sticky Bit?

One of the more confusing concepts when it comes to Linux file permissions is the sticky bit. In early Unix systems, the sticky bit was used to retain part of a program in swap space after a process exited. This had the effect of making programs load faster.  However, that's not what the sticky bit does on modern Linux systems.

Today, the sticky bit restricts who can delete files in a directory on Linux systems. Specifically, when the sticky bit is set, only the user that owns, the user that owns the directory, or the root user can delete files within the directory. In some cases, the sticky bit is more intuitively referred to as a "restricted deletion flag" or "restricted deletion bit".

The /tmp directory is one of the most common use cases for the sticky bit. Files are frequently created in /tmp for different user accounts during normal operation of many multi-user systems. If users were able to delete one another's /tmp files, it could wreak havoc on how different applications work.

Let's walk through a simple example of how the sticky bit works.

First, we'll start with a /recipes directory owned by the "cooluser" user and group.

cooluser@LAPTOP-5V55HON5:~$ ls -ld /recipes/
drwxrwxrwx 2 cooluser cooluser 4096 Oct 24 18:06 /recipes/
cooluser@LAPTOP-5V55HON5:~$

Next, we'll set the sticky bit with chmod +t /recipes/.

cooluser@LAPTOP-5V55HON5:/$ chmod +t /recipes/
cooluser@LAPTOP-5V55HON5:/$ ls -ld recipes/
drwxrwxrwt 2 cooluser cooluser 4096 Oct 24 19:00 recipes/
cooluser@LAPTOP-5V55HON5

We can see that command added a "t" to the end of the directory permissions. That "t" tells us the sticky bit is set. To test that theory, let's confirm our "seconduser" account can create files in the directory but not delete files owned by "cooluser".

First, as our "seconduser" we'll cd to /recipes/ and then we'll use touch to create a file.

seconduser@LAPTOP-5V55HON5:/recipes$ touch giardiniera.txt
seconduser@LAPTOP-5V55HON5:/recipes$ ls -l
total 4
-rw-r–r– 1 seconduser seconduser  0 Oct 24 19:18 giardiniera.txt
-rw-r–r– 1 cooluser   cooluser   83 Oct 24 19:08 pepperNegg.txt
seconduser@LAPTOP-5V55HON5:/recipes$

That worked, so now let's see if we can delete the file "cooluser" owns.

seconduser@LAPTOP-5V55HON5:/recipes$ rm pepperNegg.txt
rm: remove write-protected regular file ‘pepperNegg.txt’? y
rm: cannot remove ‘pepperNegg.txt’: Operation not permitted
seconduser@LAPTOP-5V55HON5:/recipes$

We can't! Which means the sticky bit did its job. Normally, if we have write permissions to the directory, we can delete files within it. However, in this case the sticky bit stopped us.

A Cheat Sheet: Setuid/Setgid/Sticky Bit Commands

Now that we have a basic understanding of how setuid, setgid, and the sticky bit work conceptually, let's move on to some commands for checking, setting, and removing these bits.

Checking if a file has setuid bit set

The simplest way to check if a file has the setuid bit set is to use ls -l </path/to/the/file>. If there is an "s" in the execute field for the user, the setuid is set. For example, we can see this with the passwd executable on most *nix systems.

cooluser@LAPTOP-5V55HON5:~$ ls -l /bin/passwd
-rwsr-xr-x 1 root root 68208 May 28 01:37 /bin/passwd
cooluser@LAPTOP-5V55HON5:~$

Checking if a file has setgid bit set

Like with setuid, we can use ls -l </path/to/the/file>. In this case, we simply look for the "s" in the execute field for the group.

cooluser@LAPTOP-5V55HON5:~$ ls -l /bin/wall
-rwxr-sr-x 1 root tty 35048 Apr  2  2020 /bin/wall
cooluser@LAPTOP-5V55HON5:~$

Setting the setuid bit

We can use chmod to set the setuid bit. Like with other permissions, it can be done symbolically or using octal values (numbers 0-7).

To set the setuid bit symbolically, we can use chmod u+s </path/to/the/file>.

cooluser@LAPTOP-5V55HON5:~$ chmod u+s pepperNeggMaker.sh
cooluser@LAPTOP-5V55HON5:~$ ls -l
total 0
-rwsr-xr-x 1 cooluser cooluser 0 Oct 24 19:37 pepperNeggMaker.sh
cooluser@LAPTOP-5V55HON5:~$

To set the setuid bit using octal representation we can add "4" to the front of our standard octal permissions. For example, chmod 4755 </path/to/the/file> would give the owner read, write, and execute permissions, the user and group read and execute, and set the setuid bit.

cooluser@LAPTOP-5V55HON5:~$ chmod 4755 giardinieraMixer.sh
cooluser@LAPTOP-5V55HON5:~$ ls -l
total 0
-rwsr-xr-x 1 cooluser cooluser 0 Oct 24 19:47 giardinieraMixer.sh
cooluser@LAPTOP-5V55HON5:~$

Setting the setgid bit

The setgid bit can be set in a similar fashion to the setuid bit. We simply swap the "u" to a "g" in symbolic format:

cooluser@LAPTOP-5V55HON5:~$ chmod g+s pepperNeggMaker.sh
cooluser@LAPTOP-5V55HON5:~$ ls -l
total 0
-rwxr-sr-x 1 cooluser cooluser 0 Oct 24 20:04 pepperNeggMaker.sh
cooluser@LAPTOP-5V55HON5:~$

And the "4" to a "2" in octal format:

cooluser@LAPTOP-5V55HON5:~$ chmod 2755 pepperNeggMaker.sh
cooluser@LAPTOP-5V55HON5:~$ ls -l
total 0
-rwxr-sr-x 1 cooluser cooluser 0 Oct 24 20:04 pepperNeggMaker.sh
cooluser@LAPTOP-5V55HON5:~$

Listing all files with the setuid or setgid bit set

If you want to find all files, starting from the root directory, with the setuid or setgid bit enabled, find from the GNU Findutils available on many *nix systems offers one of the easiest methods:

$ sudo find / -perm /6000 -type f

Setting the sticky bit

We can set the sticky bit on directories symbolically with chmod +t :

cooluser@LAPTOP-5V55HON5:~$ chmod +t BreakFastSpecials/
cooluser@LAPTOP-5V55HON5:/tmp$ ls -ld BreakFastSpecials/
drwxrwxrwt 2 cooluser cooluser 4096 Oct 24 20:11 BreakFastSpecials/
cooluser@LAPTOP-5V55HON5:/tmp$

Or using octal values and putting "1" in front of our standard permissions:

cooluser@LAPTOP-5V55HON5:~$ chmod 1755 BreakFastSpecials/
cooluser@LAPTOP-5V55HON5:/tmp$ ls -ld BreakFastSpecials/
drwxrwxrwt 2 cooluser cooluser 4096 Oct 24 20:11 BreakFastSpecials/
cooluser@LAPTOP-5V55HON5:/tmp$

Listing all directories with the sticky bit set

Like with our command to find all files with the setuid or setgid bit set, find from GNU's Findutils can help here:

$ sudo find / -perm /1000

Final Thoughts

With an understanding of setuid, setgid, and the sticky bit, you should now have a better understanding of Linux file permissions. Even if you don't need to create files and directories with these bits set regularly, knowing how they work is important. They impact how many different programs work. As a result understanding them can make you a better administrator and troubleshooter.