In-depth explanation of special permissions SUID, SGID and SBIT in Linux

Preface

For the permissions of files or directories in Linux, you should all know the ordinary rwx permissions (for more about rwx permissions in Linux, see my blog post http://www.cnblogs.com/javaee6/p/3994750.html). Let's first look at what the following two permissions are

It is very strange that the permissions of the /tmp directory and the passwd file are so strange. Why are there s and t permissions? You will understand after reading the following content.

setuid and setgid are abbreviations for set uid ID upon execution and set group ID upon execution, respectively. We will often abbreviate them again as suid and sgid. They are permission flags that control file access, allowing users to run executable files with the permissions of the executable file's owner or owner group, respectively.

Note: The demonstration environment of this article is Ubuntu 16.04.

SUID

In Linux, the passwords of all accounts are recorded in the file /etc/shadow, and only root can read and write this file:

If another common account tester needs to change his password, he needs to access the /etc/shadow file. But only root can access the /etc/shadow file. How is this done? In fact, the tester user can modify the password in the /etc/shadow file through the SUID function. Let's look at the permission information of the passwd program file:

The permission information in the red box in the above picture is a bit strange. The owner information is rws instead of rwx. When s appears in the x permission of the file owner, it is called SETUID BITS or SETUID, and its characteristics are as follows:

• SUID permissions are only valid for binary executable files
• If the executor has x permission on the binary executable file, the executor will have the permissions of the owner of the file.
• This permission is only valid during the execution of the binary executable file

Next, let's see how the tester user uses the SUID permission to modify the password:

• The tester user has execution permission for the /usr/bin/passwd program, so he can execute
• passwd program The owner of the passwd program is root
• The tester user will temporarily obtain root privileges when executing the passwd program.
• Therefore, the tester user can modify the /etc/shadow file during the execution of the passwd program.

However, if the tester user executes the cat command to read the /etc/shadow file, it will not work:

The reason is clear. The tester user does not have permission to read the /etc/shadow file, and the cat program is not set to SUID. We can understand these two situations through the following figure:

If you want any user to read the contents of the /etc/shadow file through the cat command, it is also very easy. Just set the SUID permission for it:

$ sudo chmod 4755 /bin/cat 

Now cat has SUID permissions. Let's see if we can cat the contents of /etc/shadow. Because this is very unsafe, quickly remove the SUID permission of cat using the following command:

$ sudo chmod 755 /bin/cat

SGID

When the s flag appears in the x permission for a group it is called an SGID. The characteristics of SGID are the same as those of SUID. We demonstrate its usage through the /usr/bin/mlocate program. The mlocate program performs fast file searches by querying the database file /var/lib/mlocate/mlocate.db. The permissions of the mlocate program are shown in the figure below:

Obviously, it has the SGID permission set. The following is the permission information of the database file /var/lib/mlocate/mlocate.db: Obviously, it is set with SGID permission. The following is the permission information of the database file /var/lib/mlocate/mlocate.db:

When ordinary user tester executes the mlocate command, tester will obtain the execution permission of the user group mlocate. Since the user group mlocate has the read permission for mlocate.db, tester can read mlocate.db. The execution process of the program is shown in the following figure:

In addition to binary programs, SGID can also be used on directories. When a directory is set with SGID permissions, it has the following functions:

• If a user has r and x permissions for this directory, the user can enter the directory
• The user's effective user group in this directory will become the user group of this directory
• If the user has the w permission in this directory, the user group of the new file created by the user is the same as the user group of the directory.

Let's take a look at an example. We create a testdir directory and set its permissions as follows:

At this time, the owner of the directory testdir is nick, and its group is tester.

First create a file called nickfile:

The permissions on this file don't look anything special. Then set SGID permissions for the testdir directory:

$ sudo chmod 2775 testdir 

Then create a file nickfile2:

The group to which the newly created file belongs is tester!

To summarize, when SGID acts on a normal file, similar to SUID, when the file is executed, the user will obtain the permissions of the group to which the file belongs. When SGID is applied to directories, it has a very significant meaning. When a user has write and execute permissions for a directory, the user can create files in the directory. If the directory is modified with SGID, the files created by the user in the directory belong to the group to which the directory belongs.

SBIT

In fact, SBIT has little to do with SUID and SGID.

SBIT is the abbreviation for the restricted deletion flag or sticky bit.

SBIT currently only works on directories and is used to prevent non-file owners from deleting files. A common example is the /tmp directory:

The last t in the permission information indicates that the directory is set with SBIT permission. The effect of SBIT on a directory is: when a user creates a new file or directory in the directory, only the user and root have the authority to delete it.

Note: SBIT does not work on files.

Set SUID, SGID, SBIT permissions

Setting permissions numerically

The numbers corresponding to SUID, SGID, and SBIT permissions are as follows:

SUID->4
SGID->2
SBIT->1

So if you want to set SUID permissions for a file with file permissions of "-rwxr-xr-x", you need to add 4 in front of the original 755, that is, 4755:

$ chmod 4755 filename

Similarly, you can use 2 and 1 to set the SGID and SBIT permissions. After the setting is completed, s, s, and t will replace the x in the file permissions respectively.

In fact, S and T situations may also occur. S and t are replacements for the x permission. However, if it does not have the x permission, it will be displayed as a capital S or a capital T after adding the SUID, SGID, or SBIT permission. For example, we add SUID, SGID, and SBIT permissions to a file with permission 666:

Execute chmod 7666 nickfile. Because 666 means "-rw-rw-rw", which has no x permission, it finally becomes "-rwSrwSrwT".

Changing permissions by symbol type

In addition to using numbers to modify permissions, you can also use symbols:

$ chmod u+s testfile # Add SUID permission to the testfile file.
$ chmod g+s testdir # Add SGID permission to the testdir directory.
$ chmod o+t testdir # Add SBIT permission to the testdir directory.

Summarize

SUID, SGID, and SBIT permissions are designed to implement special functions, and their purpose is to make up for some usage scenarios that ugo permissions cannot achieve.

refer to:

• chmod man page
• setuid - Wikipedia
• The wonderful uses of SUID, SGID and SBIT in Linux
• Linux special permissions SUID, SGID, SBIT