How to use SUID, SGID, and Sticky Bits on Linux

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 /etc/shadow File.

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 sudo).

this is the code that recognizes if someone is root.

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.

A source code snippet from

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.

If the 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 passwd Command:


the passwd Prompts dave for his new password. We can use that ps command to see the details of running processes.

We use ps with grep in another terminal window and look for the passwd Process. We will too -e (any process) and -f (Full format) options with ps.

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 passwd process dave started.

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 chmod. the u+s symbolic mode sets the SUID bit and the u-s symbolic mode clears the SUID Bit.

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 /usr/local/bin Portfolio:


Even though 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 u-s and g+s symbolic modes with chown to remove the SUID Bit and set the SGID.

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 dave and 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 dave.

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 mary Group.

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

the SGID Bit and group “Geek” are set. These affect all elements within the. were created work Directory.

We enter the following to enter the work Directory, create a directory called “demo” and check its properties:

cd work
mkdir demo
ls -lh -d demo

the 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

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 /tmp and /var/tmp Directories.

We enter the following commands:

mkdir shared
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.

the /tmp and /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:

  • SUID only works with files.
  • You can apply SGID to directories and files.
  • You can only apply the sticky bit to directories.
  • If the “s“,”g“, or “t”Displays appear in capital letters, the executable bit (x) is not set.

Related Posts