Shulou(Shulou.com)06/01 Report--

Editor to share with you the Linux special permissions SUID, SGID and SBIT example analysis, I believe that most people do not know much about it, so share this article for your reference, I hope you will learn a lot after reading this article, let's go to know it!

Preface

For the permissions of files or directories in linux, you should all know the normal rwx permissions. Let's first take a look at the permissions of the following two.

It's very strange that the permissions of the / tmp directory and passwd files are weird, and why do you have s and t permissions? You will understand after reading the following content.

Setuid and setgid are abbreviations for setuid ID upon execution and set group ID upon execution, respectively. We usually abbreviate them as suid and sgid again. They are permission flags (flag) that control file access, and they allow users to run executable files with the permissions of the owner or owner group of the executable, respectively.

Description: the demo environment for 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 to this file:

If another regular account tester needs to change its password, access the / etc/shadow file. But obviously only root can access / etc/shadow this file, how on earth is this done? In fact, tester users can change the password in the / etc/shadow file through the SUID function. Let's take a look at the permission information of the passwd program file:

The permission information in the red box above is a little strange. The information for owner is rws, not rwx. When s appears on the x permission of the file owner, it is called SETUID BITS or SETUID and has the following characteristics:

SUID permissions are valid only for binary executable files

If the executor has x permission for the binary executable file, the executor will have the permission of the owner of the file

This permission is valid only during the execution of the binary executable

Let's take a look at how tester users use SUID permissions to change their passwords:

The tester user has execute permissions on the / usr/bin/passwd program, so it can execute

The owner of the passwd program passwd program is root

Tester users will temporarily get root permission during the execution of passwd programs.

Therefore, tester users can modify the / etc/shadow file during the execution of the passwd program

But it doesn't work if the tester user executes the cat command to read the / etc/shadow file:

The reason is clear that 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 it is also very easy for any user to read the contents of the / etc/shadow file through the cat command, just set the SUID permission to it:

$sudo chmod 4755 / bin/cat

Now that cat has SUID permission, try to see if it is possible to cat to / etc/shadow content. Because this is very unsafe, quickly remove the SUID permission from cat with the following command:

$sudo chmod 755 / bin/cat

SGID

When the s flag appears in the x permission of the user group, it is called SGID. SGID has the same characteristics as SUID, and we demonstrate its usage through the / usr/bin/mlocate program. The mlocate program realizes fast file search by querying the database file / var/lib/mlocate/mlocate.db. The permissions of the mlocate program are shown in the following figure:

It is obvious that it is set with SGID permissions. Here is the permission information for the database file / var/lib/mlocate/mlocate.db: obviously, it is set with SGID permissions. The following is the permission information for the database file / var/lib/mlocate/mlocate.db:

When the ordinary user tester executes the mlocate command, tester will get the execution permission of the user group mlocate, and because the user group mlocate has read permission to the mlocate.db, tester can read the mlocate.db. The execution of the program is shown in the following figure:

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

If a user has r and x permissions on this directory, the user can enter the directory

The valid user group of the user under this directory will become the user group of the directory.

If the user has w permissions in this directory, the user group for the new file created by the user is the same as the user group in that directory

Let's take a look at an example. Create a testdir directory with the following permissions:

At this point, the owner of the directory testdir is nick and the group to which it belongs is tester.

First create a file called nickfile:

There seems to be nothing special about the permissions of this file. Then set the SGID permission to the testdir directory:

$sudo chmod 2775 testdir

Then create a file called nickfile2:

The new file belongs to a group of tester!

To sum up, when SGID acts on a normal file, similar to SUID, when the file is executed, the user will be given permission to the group to which the file belongs. When SGID acts on a directory, it makes a lot of sense. When a user has write and execute permissions to a directory, the user can create files in that directory. If the directory is decorated with SGID, the files created by the user in this 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 of the restricted deletion flag or sticky bit.

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

The last bit t in the permission information indicates that the directory has SBIT permission set. What SBIT does to a directory is that when a user creates a new file or directory under that directory, only himself and root have the right to delete it.

Note: SBIT does not work on files.

Set SUID, SGID, SBIT permissions

Set permissions digitally

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

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

So if you want to set the SUID permission for a file with a file permission of "- rwxr-xr-x", you need to add 4, or 4755, before the original 755:

$chmod 4755 filename

Similarly, SGID and SBIT permissions can be set with 2 and 1. After the setting is completed, the x in the file permissions will be replaced by s, s, t, respectively.

In fact, there may also be cases of S and T. S and t replace the permission of x, but if it does not have the permission of x, it will appear as uppercase S or uppercase T after adding SUID, SGID, and SBIT permissions. For example, we add SUID, SGID and SBIT permissions to a file with a permission of 666:

Execute chmod 7666 nickfile, because it means "- rw-rw-rw" and does not have x permission, so it finally becomes "- rwSrwSrwT".

Change permissions by symbol type

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

$chmod Utility testfile # adds SUID permissions to the testfile file. $chmod gems testdir # adds SGID permissions to the testdir directory. $chmod testdir # adds SBIT permissions to the testdir directory. The above is all the contents of the article "sample Analysis of SUID, SGID and SBIT with Special permissions in Linux". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.