Special permission of CentOS system suid sgid sticky explanation


1. What is special authority?

We know the permissions are R, W, X. In fact, in addition to these three, there are special permissions. For example:

[[email protected] ~]# ls -l /usr/bin/passwd

                                     -rwsr-xr-x 1 root root 22960 Jul 17  2006 /usr/bin/passwd

The permission bit can be found. There is an S. There are three types of special permissions:




2. about suid

We know that Linux has a concept of process security model. For example, Tom executes passwd to modify the password:

First, note that the permissions for passwd are:

[[email protected] ~]$ ls -l `which passwd`

-rwsr-xr-x 1 root root 22960 Jul 17  2006 /usr/bin/passwd

Second, notice that Tom is not root and does not belong to the root group.

We don’t think about special permissions first. Obviously, Tom can only run passwd with other (R-X) at this time. Tom can start a process, which is passwd. He wants to change his password.

Third, when Tom finishes executing passwd to change the password, it is actually saved to / etc / shadow. Let’s see the permissions of the / etc / shadow file.

[[email protected] ~]$ ls -l /etc/shadow

-r——– 1 root root 2713 Jun 13 16:34 /etc/shadow

[[email protected] ~]$ 

The password modification process belonging to Tom should modify the / etc / shadow file, but according to the above permissions of / etc / shadow, no one can modify except root! That is to say, according to the process security model, ordinary users can’t change the password at all! But in fact, it can be modified. The reason is that special permission s.

That is to say, suid means that when running a program, the owner of the corresponding process is the owner of the program file itself, not the initiator. That is to say, ordinary users execute passwd to change passwords. In fact, they initiate a process. The owner of this process is root, so it is obvious that they can modify shadow files.

3. about sgid

According to the understanding of suid, sgid means that when running a program, the group of the corresponding process is the group of the program file itself, not the basic group of the initiator. For example:

First: the root user creates a project directory

[[email protected] /]# 

[[email protected] /]# ls -ld /project/cma

drwxrwxr-x 2 root develop 4096 Jun 14 22:14 /project/cma

Second: project team members java01, java02,… Belong to the development group (their additional group), that is, they have RWX permission to / project / CMA.

[[email protected] cma]$ ls -l

total 8

-rw-rw-r– 1 java01 java01 0 Jun 14 22:24 01.java

-rw-rw-r– 1 java02 java02 0 Jun 14 22:25 02.java

It can be seen above that they can create files in / project / CMA. According to the previous theory, whoever creates a file, the owner of the file is who, and the group is his basic group. There is no problem with the above. However, we hope that these project team members can edit each other’s files. What should we do?

Third: because the project team member java02 does not belong to the private group of java01, it is obvious that java02 only has r-permission to 01. Java and cannot be edited. At this point, we can use sgid to change the default behavior~

[[email protected] cma]# pwd


[[email protected] cma]# chmod -R g+s /project/cma 

[[email protected] cma]# ls -ld

drwxrwsr-x 2 root develop 4096 Jun 14 22:25 .

[[email protected] cma]# 

Note that the special permission bit s appears, but sometimes s may be displayed. [if it is s, it means that the permission bit has x permission before]

Fourth: after using sgid, our project team members can edit other members’ files in this directory.

[[email protected] cma]$ ls -l

total 16

-rw-rwSr– 1 java01 java01  0 Jun 14 22:24 01.java

-rw-rw-r– 1 java01 develop 0 Jun 14 22:33 01.txt

-rw-rwSr– 1 java02 java02  0 Jun 14 22:25 02.java

-rw-rw-r– 1 java02 develop 0 Jun 14 22:33 02.txt

[[email protected] cma]$ 

That is to say, sgid can help us achieve this goal:

The file’s group created in the directory is not the user’s basic group, but the directory’s group.

4. About sticky

At this moment, our project team members can edit the files under / project / CMA, but there is a requirement: we hope that users can only delete their own files, not others’ files. This is about using sticky.

[[email protected] cma]# chmod -R o+t /project/cma

[[email protected] cma]$ id

uid=5016(java01) gid=5016(java01) groups=5016(java01),5018(develop) context=root:system_r:unconfined_t:SystemLow-SystemHigh

[[email protected] cma]$ rm 02.txt

rm: cannot remove `02.txt’: Operation not permitted

5. series

Remember umask? Umask is actually a xyzw with four digits, where X represents suid / sgid / striky.

Chmod xyzw file, in fact, the same.

000 nothing

001 only striky

010 only sgid

100 only suid


Recommended Today

Notes on tensorflow 2 deep learning (I) tensorflow Foundation

This series of notes records the process of learning tensorflow2, mainly based on https://github.com/dragen1860/Deep-Learning-with-TensorFlow-book Learning First of all, it needs to be clear that tensorflow is a scientific computing library for deep learning algorithm, and the internal data is stored in theTensor objectAll operations (OPS) are also based on tensor objects. data type Fundamentals in […]