SUID:
When s appears on the x permission of the file owner, it is called setupid bits or setupid. Its characteristics are as follows:
- 1.SUID permission is only valid for binary executables
- 2. If the performer has x permission on the binary executable, the performer will have the permission of the owner of the file
- 3. This permission is only valid during the execution of the binary executable
- 4. If the file owner does not have execution permission, use the capital S here
example:
[root@node01 ~]# ll /etc/shadow ---------- 1 root root 799 Nov 27 13:47 /etc/shadow [root@node01 ~]# [root@node01 ~]# cat /etc/shadow | head -1 root:$6$.Kpje8ue$HbRr7y12HEhEHN1Ma4p1y7VMbHz627ApYRNGF7qav.7VbQTgLr9/4rZYV.1KsjVFFO4hoyGCkI9hMLU6tztV70:18875:0:99999:7::: [root@node01 ~]# [root@node01 ~]# useradd test1 [root@node01 ~]# su - test1 [test1@node01 ~]$ cat /etc/shadow cat: /etc/shadow: Permission denied [test1@node01 ~]$ exit logout [root@node01 ~]# chmod u+s /bin/cat [root@node01 ~]# su - test1 Last login: Sat Nov 27 13:47:55 CST 2021 on pts/0 [test1@node01 ~]$ cat /etc/shadow | head -1 root:$6$.Kpje8ue$HbRr7y12HEhEHN1Ma4p1y7VMbHz627ApYRNGF7qav.7VbQTgLr9/4rZYV.1KsjVFFO4hoyGCkI9hMLU6tztV70:18875:0:99999:7::: [test1@node01 ~]$ exit logout [root@node01 ~]# chmod u-s /bin/cat [root@node01 ~]#
Originally, ordinary user test1 could not read the contents of / etc/shadow, but when root
After adding SUID permission to the cat command, ordinary user test1 can read the contents of the original file / etc/shadow through the cat command
SGID
When the s flag appears in the x limit of the user group, it is called SGID. SGID has the same characteristics as SUID. We demonstrate its usage through the / usr/bin/mlocate program. Mlocate program realizes fast file search by querying the database file / var/lib/mlocate/mlocate.db. The permissions of the mlocate program are as follows:
[root@node01 ~]# ll /usr/bin/locate -rwx--s--x 1 root slocate 40520 Apr 11 2018 /usr/bin/locate [root@node01 ~]#
Obviously, it is set with SGID permission. The following is the permission information of the database file / var/lib/mlocate/mlocate.db:
[root@node01 ~]# ll /var/lib/mlocate/mlocate.db -rw-r----- 1 root slocate 13064707 Nov 27 15:01 /var/lib/mlocate/mlocate.db
When the ordinary user tester executes the locate command, the tester will obtain the execution permission of the user group slocate. Because the user group slocate has read permission to mlocate.db, the 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 SGID permission is set for a directory, it has the following functions:
- If the user has r and x permissions on this directory, the user can enter the directory
- The user's valid user group under this directory will become the user group of this directory
- If the user has w permission in this directory, the user group of the new file created by the user is the same as that of the directory
example
ll -d /mnt/sgid chmod o+w /mnt/sgid ll -d /mnt/sgid userdel -r test1 useradd test1 su - test1 touch /mnt/sgid/test1 ll /mnt/sgid/test1 chmod g+s /mnt/sgid userdel -r test2 useradd test2 su - test2 touch /mnt/sgid/test2 ll /mnt/sgid/test2
- Practical demonstration
[root@node01 ~]# ll -d /mnt/sgid drwxr-xr-x 2 root root 4096 Nov 27 13:39 /mnt/sgid [root@node01 ~]# chmod o+w /mnt/sgid [root@node01 ~]# ll -d /mnt/sgid drwxr-xrwx 2 root root 4096 Nov 27 13:39 /mnt/sgid [root@node01 ~]# userdel -r test1 useradd test1 su - test1 touch /mnt/sgid/test1[root@node01 ~]# useradd test1 [root@node01 ~]# su - test1 [test1@node01 ~]$ touch /mnt/sgid/test1 [test1@node01 ~]$ ll /mnt/sgid/test1 -rw-rw-r-- 1 test1 test1 0 Nov 27 22:35 /mnt/sgid/test1 [test1@node01 ~]$ chmod g+s /mnt/sgid chmod: changing permissions of '/mnt/sgid': Operation not permitted [test1@node01 ~]$ exit logout [root@node01 ~]# chmod g+s /mnt/sgid [root@node01 ~]# ll /mnt/sgid -d drwxr-srwx 2 root root 4096 Nov 27 22:35 /mnt/sgid [root@node01 ~]# userdel -r test2 userdel: user 'test2' does not exist [root@node01 ~]# useradd test2 [root@node01 ~]# su - test2 touch /mnt/sgid/test2 ll /mnt/sgid/test2Last failed login: Fri Nov 26 07:15:17 CST 2021 from 47.110.150.3 on ssh:notty There were 8 failed login attempts since the last successful login. [test2@node01 ~]$ touch /mnt/sgid/test2 [test2@node01 ~]$ ll /mnt/sgid/test2 -rw-rw-r-- 1 test2 root 0 Nov 27 22:35 /mnt/sgid/test2 [test2@node01 ~]$
- summary
When SGID acts on a normal file, similar to SUID, when executing the file, the user will obtain the permission of 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 on 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
SBIT is currently only valid for directories and is used to prevent non file owners from deleting files. A common example is the / tmp directory
- example
userdel -r test1 userdel -r test2 userdel -r test3 rm -rf /mnt/sbit mkdir -p /mnt/sbit ll -d /mnt/sbit chmod o+w /mnt/sbit ll -d /mnt/sbit useradd test1 useradd test2 useradd test3 su - test1 touch /mnt/sbit/test1 ll /mnt/sbit/test1 exit su - test2 touch /mnt/sbit/test2 ll /mnt/sbit/test2 ll /mnt/sbit rm -f /mnt/sbit/test1 ll /mnt/sbit exit chmod o+t /mnt/sbit su - test3 touch /mnt/sbit/test3 ll /mnt/sbit rm -f /mnt/sbit/test2
- Practical demonstration
[root@node01 ~]# userdel -r test1 userdel: user 'test1' does not exist [root@node01 ~]# userdel -r test2 userdel: user 'test2' does not exist [root@node01 ~]# userdel -r test3 userdel: user 'test3' does not exist [root@node01 ~]# rm -rf /mnt/sbit [root@node01 ~]# mkdir -p /mnt/sbit ll -d /mnt/sbit[root@node01 ~]# ll -d /mnt/sbit drwxr-xr-x 2 root root 4096 Nov 27 22:44 /mnt/sbit [root@node01 ~]# chmod o+w /mnt/sbit [root@node01 ~]# ll -d /mnt/sbit drwxr-xrwx 2 root root 4096 Nov 27 22:44 /mnt/sbit [root@node01 ~]# useradd test1 [root@node01 ~]# useradd test2 [root@node01 ~]# useradd test3 [root@node01 ~]# su - test1 ll /mnt/sbit/test1[test1@node01 ~]$ touch /mnt/sbit/test1 [test1@node01 ~]$ ll /mnt/sbit/test1 -rw-rw-r-- 1 test1 test1 0 Nov 27 22:44 /mnt/sbit/test1 [test1@node01 ~]$ exit logout su - test2 touch /mnt/sbit/test2[root@node01 ~]# su - test2 Last failed login: Sat Nov 27 22:43:38 CST 2021 on pts/0 There were 10 failed login attempts since the last successful login. [test2@node01 ~]$ touch /mnt/sbit/test2 [test2@node01 ~]$ ll /mnt/sbit/test2 -rw-rw-r-- 1 test2 test2 0 Nov 27 22:44 /mnt/sbit/test2 [test2@node01 ~]$ ll /mnt/sbit total 0 -rw-rw-r-- 1 test1 test1 0 Nov 27 22:44 test1 -rw-rw-r-- 1 test2 test2 0 Nov 27 22:44 test2 [test2@node01 ~]$ rm -f /mnt/sbit/test1 [test2@node01 ~]$ ll /mnt/sbit total 0 -rw-rw-r-- 1 test2 test2 0 Nov 27 22:44 test2 [test2@node01 ~]$ exit logout chmod o+t /mnt/sbit[root@node01 ~]# chmod o+t /mnt/sbit [root@node01 ~]# su - test3 touch /mnt/sbit/test3 ll /mnt/sbit[test3@node01 ~]$ touch /mnt/sbit/test3 [test3@node01 ~]$ ll /mnt/sbit total 0 -rw-rw-r-- 1 test2 test2 0 Nov 27 22:44 test2 -rw-rw-r-- 1 test3 test3 0 Nov 27 22:45 test3 [test3@node01 ~]$ rm -f /mnt/sbit/test2 rm: cannot remove '/mnt/sbit/test2': Operation not permitted [test3@node01 ~]$
- Other precautions
The user can only run and enter the directory if he has execution permission. Otherwise, even if he has write permission, he cannot write to the directory
- example
[root@node01 ~]# mkdir /mnt/test [root@node01 ~]# ll /mnt/test -d drwxr-xr-x 2 root root 4096 Nov 27 14:11 /mnt/test [root@node01 ~]# chmod o-x,o+w /mnt/test [root@node01 ~]# ll /mnt/test -d drwxr-xrw- 2 root root 4096 Nov 27 14:11 /mnt/test [root@node01 ~]# su - test1 Last login: Sat Nov 27 13:48:08 CST 2021 on pts/0 [test1@node01 ~]$ cd /mnt/test -bash: cd: /mnt/test: Permission denied [test1@node01 ~]$ touch /mnt/test/test1 touch: cannot touch '/mnt/test/test1': Permission denied [test1@node01 ~]$
lsattr and chatr
- Look directly at the code
[root@node01 ~]# touch /mnt/test_attr [root@node01 ~]# ll /mnt/test_attr -rw-r--r-- 1 root root 0 Nov 27 22:48 /mnt/test_attr [root@node01 ~]# lsattr /mnt/test_attr -------------e-- /mnt/test_attr [root@node01 ~]# [root@node01 ~]# echo 'hello' >> /mnt/test_attr [root@node01 ~]# [root@node01 ~]# chattr +i /mnt/test_attr [root@node01 ~]# echo 'hello' >> /mnt/test_attr -bash: /mnt/test_attr: Permission denied [root@node01 ~]# ll /mnt/test_attr -rw-r--r-- 1 root root 6 Nov 27 22:48 /mnt/test_attr [root@node01 ~]# lsattr /mnt/test_attr ----i--------e-- /mnt/test_attr [root@node01 ~]#
getfacl and setfacl
[root@node01 ~]# su - test1 Last login: Sat Nov 27 22:44:43 CST 2021 on pts/0 [test1@node01 ~]$ ls /root ls: cannot open directory /root: Permission denied [test1@node01 ~]$ exit logout [root@node01 ~]# setfacl -m u:test1:rwx /root [root@node01 ~]# su - test1 Last login: Sun Nov 28 18:33:40 CST 2021 on pts/0 [test1@node01 ~]$ ls /root/ history lxm mysql psycopg3 remove_docker test [test1@node01 ~]$ exit logout [root@node01 ~]# getfacl /root/ getfacl: Removing leading '/' from absolute path names # file: root/ # owner: root # group: root user::r-x user:test1:rwx group::r-x mask::rwx other::---
You can see that test1 cannot view the files in the / root directory, but after setting, test1 can view the / root directory
reference resources:
https://www.cnblogs.com/fhefh/archive/2011/09/20/2182155.html
https://www.cnblogs.com/sparkdev/p/9651622.html