Linux file special permissions

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

Tags: Linux PostgreSQL SQL

Posted on Sun, 28 Nov 2021 12:42:58 -0500 by Catfish