Special permissions for Linux (suid/sgid/sbit)

Introduction to special permissions set UID

When s this flag appears on the file owner's X permission, such as/usr/bin/passwd the permission state of this file: "-rwsr-xr-x.", this is called the set UID, referred to as suid. So what is the specific function of this particular privilege?
1. SUID permission is only valid for binary program (binary programs);
2, the performer for the program needs to have the executable permission of X;
3. This permission is valid only in the process of executing the program (run-time);
4. The executor will have the permission of the owner of the program.
The purpose of SUID is to allow users who do not have the appropriate permissions to run the program to access resources that they do not have access to. PASSWD is a very vivid example, let's take a look at the process of this phase passwd execution.
We know that the user password in the system is stored in the/etc/shadow, and the permissions of this file are----------. (This permission differs from previous versions of Rhel, formerly-R--------). In fact, there is no r permission is not important, because our root user has the highest authority, what can do. The key is to write the password to the/etc/shadow. We know that in addition to the root user can change the password, the user can also change the password, why no write permission, but also can change the password, because of this suid function.

The following is the execution of the passwd command.
1. Because/USR/BIN/PASSWD permissions are available to any user, each user in the system can execute this command.
2, and/usr/bin/passwd This file permissions are root.
3. When a user executes the/USR/BIN/PASSWD command, he or she has root privileges.
4, so that a user can use the root user's power to modify the/etc/shadow file.
5, finally, the password to modify the success.

Note: This suid can only be run on a binary program (some commands in the system) and cannot be used in scripts (script), because the script will be able to assemble many programs together, rather than executing the script itself. Similarly, this suid can not be placed in the directory, put on is also invalid.

Set GID

As we said earlier, when the S flag appears on the file owner's X-permission, it is called the set UID. Then put this s to the user group X location of the file, that is Sgid. such as the/usr/bin/wall command at the beginning.
So what is the function of Sgid? Just like Suid, Sgid is the right to get the user group that the program belongs to.
There are a few points that need our attention in this phase sgid:
1, Sgid is useful for binary program;
2, the program executor for the program, the need to have access to X;
3, Sgid mainly used in the directory;
Understanding the Suid, I think Sgid is also very easy to understand. If the user has the W permission in this directory, the new file will have the same group as the group in this directory if the consumer creates a new file under this directory.

Sticky Bit

This is for others to set up, and the above two, just like the function is different.
Sbit (Sticky Bit) is currently only valid for the directory, the role of the directory is: when the user in this directory to create a file or directory, only their own and root have the right to delete.
The most representative is the/tmp directory, anyone can add and modify files in/tmp (because the permissions are all rwx), but only the file/directory creator and Root can delete their own directories or files.

Note: This sbit does not work for files.

Suid/sgid/sbit permission settings

Similar to what we said earlier, there are two ways of rwx, one is in characters, and the other is in numbers.
4 for SUID = U+s
2 for SGID = G+s
1 for sbit = O+t
Let's take a look at how to set it up and see how it works.

First look at the function and setting of SUID

[Email protected] ~]# cd/tmp/
[[Email protected]Japietmp]# cp/usr/bin/passwd./
[[Email protected]Japietmp]# mkdir TestDir
The above two steps are to create the passwd file and the TestDir directory in the/tmp directory
Here's a look at these two permissions
[[Email protected]Japietmp]# ls-l passwd; Ls-ld testdir/
-rwxr-xr-x. 1 root root 26968 Jan 23:27 passwd
Drwxr-xr-x. 2 root root 4096 Jan 19:25 testdir/
We switch to the Yufei user and then modify our own password
[[Email protected]Japietmp]# su Yufei
[[Email protected]JapieI tmp]$./passwd
changing password for userJapie.
changing password for Yufei.
(current) UNIX Password:
New Password:
Retype new Password:
Passwd:authentication Token manipulation Error
found that the above Yufei can not change their own password, why? It is because there is no permission to write the password to the/etc/shadow. If you want ordinary users to be able to modify/etc/shadow, then you need to use SUID.
[[Email protected]Japietmp]$ su Root
Password:
[[Email protected]Japietmp]# chmod u+s passwd
[[Email protected]japie tmp]# ls-l passwd
-rwsr-xr-x. 1 root root 26968 Jan 23:27 pas swd 
See Suid permission, and then modify Yufei own password
[[email protected]  japie tmp]$./PASSWD
Changing password for user Yufei.
changing password for Yufei.
(current) UNIX password:
New password:
Retype new password:
Passwd:all authentication Tokens updated successfully. 
We found it was successful.
I think about it, you already know the role of suid.
If you want to change this back (that is, to remove suid permissions), we use the digital way to set
[[email protected]  japie tmp]# chmod 0755 passwd
[[email protected] < Span class= "Mycode" >japie tmp]# ls-l passwd
-rwxr-xr-x. 1 root root 26968 Jan 23:27 PASSW d 
OK this is changed, the principle of the figure and the rwx we said earlier is the same, just set the corresponding number in the front.

Note: In the ordinary user to modify their own password is, password to set the complex point, otherwise, through certification, ordinary users and root user permissions are different.

Look at the function and setting of Sgid

Let's take the example of the/tmp/testdir created earlier.
[[Email protected]Japietmp]# Ls-ld testdir/
[[Email protected]Japietmp]# chmod 757 testdir/
[[Email protected]Japietmp]# Ls-ld testdir/
Drwxr-xrwx. 2 root root 4096 Jan 19:25 testdir/
At this point, any user has write access to this directory, then we create files and directories in this directory and see how their permissions
[[Email protected]Japietmp]# suJapie
[[Email protected]Japietmp]$ Touch Testdir/file1
[[Email protected]Japietmp]$ mkdir Testdir/dir1
[[Email protected]Japietmp]$ ls-l TestDir
Total 0
Drw-rw-r--. 1JapieJapie0 Jan 10:33 Dir1
-rw-rw-r--. 1JapieJapie0 Jan 10:33 File1
The file and directory permissions at this time are the creators themselves
Let's take a look at the effect of creating files and directories after adding Sgid permissions to this directory.
[Japie@Japietmp]$ su Root
Password:
[[Email protected]Japietmp]# chmod g+s testdir/
[[Email protected]Japietmp]# Ls-ld testdir/
Drwxr-srwx. 2 root root 4096 Jan 10:33 testdir/
[[Email protected]Japietmp]# su Yufei
[[Email protected]Japietmp]$ Touch Testdir/file2
[[Email protected]Japietmp]$ mkdir Testdir/dir2
[[Email protected]Japietmp]$ ls-l testdir/
Total 0
Drw-rw-r--. 1JapieJapie0 Jan 10:33 Dir1
Drw-rw-r--. 1JapieRoot 0 Jan 10:36 Dir2
-rw-rw-r--. 1Japiei japie 0 (Jan) 10:33 file1
- Rw-rw-r--. 1 japie root  0 Jan 10:35 file2
[[email  Protected] japie tmp]$ ls-ld testdir/
drwxr-srwx. 2 root Root 4096 Jan 10:36 testdir/ 
At this point we found that the user groups of File2 and Dir2 became root, which is the user group of their upper directory TestDir this directory.
This application is very convenient for the common development of a project.
[[email protected] japie tmp ]$ su root
Password:
[[Email protected] japie tmp ]# chmod g-s testdir/
[[Email protected] japie tmp]$ Ls-ld testdir/
drwxr-xrwx. 2 root root 4096 Jan 10:36 testdir/ 
This restores the

Finally, we look at the role and setting of Sbit

[[Email protected]Japietmp]# rm-fr testdir/*
[[Email protected]Japietmp]# Ls-ld testdir/
Drwxr-xrwx. 2 root root 4096 Jan 11:42 testdir/
Empty all contents of the/tmp/testdir/directory.
We switch to a normal user, and then create the file inside, at least two ordinary users to test this, if not, build on their own.
[[Email protected]Japietmp]# suJapie
[[Email protected]Japietmp]$ Touch testdir/Japie_file
[[Email protected]JapieI tmp]$ ls-l testdir/
Total 0
-rw-rw-r--1JapieJapie0 Jan 21 11:45Japie_file
This is when we set up a file and we switch to another user.
[[Email protected]Japietmp]$ su opsers
Password:
[[Email protected]Japietmp]$ Ls-ld testdir/
Drwxr-xrwx. 2 root root 4096 Jan 11:45 testdir/
We see that while other users have only read-only access to Yufei_file,Japie _file is located in the directory, the other people are full of permissions, so we can change other users or delete this file, see the operation
[[Email protected]Japietmp]$ rm-f testdir/Japie_file
[[Email protected]Japietmp]$ ls testdir/
Discover that we have removed this permission that does not belong to us.
Now let's add sbit permission to this directory and see the effect.
[[Email protected]Japietmp]$ su Root
Password:
[[Email protected]Japietmp]# chmod o+t TestDir
[[Email protected]Japietmp]# Ls-ld testdir/
DRWXR-XRWT. 2 root root 4096 Jan 11:49 testdir/
Switch normal user Once more, create file
[[Email protected]Japietmp]# suJapie
[[Email protected]Japietmp]$ Touch testdir/Japie_file
[[Email protected]Japietmp]$ ls-l testdir/Japie_file
-rw-rw-r--1JapieJapie0 Jan 11:51 testdir/Japie_file
The permissions of this file is the same as the first time it was created, we will change to another user to see if we can delete this file again
[[Email protected]Japie tmp]$ su opsers
Password:
[Email protected] japie tmp]$ rm-f testdir/ japie _file
Rm:cannot Remove ' testdir/ japie _file ': Operation not permitted
See the prompt, say that the permissions are not enough, can only be deleted by this file creator or root user. We're not going to show this.
If you want to restore permissions,
[Email protected] Japie tmp]$ su Root
Password:
[Email protected] japie tmp]# chmod o-t TestDir
[Email protected] japie tmp]# ls-ld testdir/
Drwxr-xrwx. 2 root root 4096 Jan 11:51 testdir/

Two issues to be aware of

OK, we have already finished the application and function of these special privileges on suid/sgid/sbit. But if you are careful, you will find that I have not used the digital way to change this particular privilege, why? And look at the following analysis.

Issue 1: Changing the special permissions of the directory with numbers does not work.

We put the/tmp/below and we set up the experimental file to delete
[[Email protected]Japietmp]# rm-fr testdir/
[[Email protected]Japietmp]# rm-fr passwd
And then recreate a file and directory,
[[Email protected]Japietmp]# cp/usr/bin/passwd./
[[Email protected]Japietmp]# mkdir TestDir
[[Email protected]Japietmp]# ls-l passwd; ls-ld testdir/
-rwxr-xr-x 1 root root 26968 Jan passwd
Drwxr-xr-x 2 root root 4096 Jan testdir/
Let's use the digital way to change these three special permissions to see what the results are.
[Email protected] tmp]# chmod 4755 passwd
[Email protected] tmp]# chmod 3755 testdir/
[Email protected] tmp]# ls-l passwd; ls-ld testdir/
-rwsr-xr-x 1 root root 26968 Jan passwd
Drwxr-sr-x 2 root root 4096 Jan testdir/
It's not a problem to add these three special permissions in this way, so let's change the authority back to see
[Email protected] japie tmp]# chmod 0755 passwd
[Email protected] japie tmp]# chmod 0755 testdir/
[Email protected] japie tmp]# ls-l passwd; ls-ld testdir/
-rwxr-xr-x 1 root root 26968 Jan passwd
Drwxr-sr-x 2 root root 4096 Jan testdir/
We found that the file, permission is changed back, and for the directory, only changed back to the sbit of the rights, SUID and Sgid change not back. Is this an experimental result on RHEL6, perhaps for safety reasons? I don't know that, and I can't find the relevant information. If you have a friend, you know what the reason, welcome to contact me. I thanked you first.
So, it is recommended to use the most clear way, directly with +-to change, no matter how the method, the final result will be OK. haha ...

Question 2: Why there are uppercase S and T.

Or use the files and directories above
[[Email protected]Japietmp]# ls-l passwd; ls-ld testdir/
-rwxr-xr-x 1 root root 26968 Jan passwd
Drwxr-sr-x 2 root root 4096 Jan testdir/
We're removing passwd and TestDir's X-rights.
[[Email protected]Japietmp]# chmod u-x passwd
[[Email protected]Japietmp]# chmod o-x testdir/
[[Email protected] japie < Span class= "Mycode" >tmp]# ls-l passwd; ls-ld testdir/
-rw-r-xr-x 1 root root 26968 Jan passwd
drwxr-sr-- 2 root root 4096 Jan testdir/ 
Add suid and Sbit permissions
[[email protected]  japie tmp]# chmod u+s passwd
[[email protected]  japie tmp]# chmod o+t testdir/
[[email protected]  japie tmp]# ls-l passwd; ls-ld testdir/
-rwsr-xr-x 1 root Root 26968 Jan passwd
drwxr-sr-t 2 root root 4096 Jan testdir/ 
We see that this time the little s and the little t have become big s and Big T, why It? Because they do not have X permission in this position, if there is no X permission, according to what we said above, in fact, this special permission is equivalent to an empty permission, meaningless. In other words, if you see the special permission position becomes uppercase, then, it indicates that there is a problem, need to be excluded.

Special permissions for Linux (suid/sgid/sbit)