『学了就忘』Linux权限管理 — 55、文件特殊权限

1、文件特殊权限说明

Linux系统中，文件特殊权限有：SetUID，SetGID，Sticky BIT。

这三个文件权限不是太安全，是Linux系统应对特殊情况所准备的权限，给Linux系统的一些特殊命令提供的。不推荐用户手动来设置，尤其是SetUID。这三个选项了解一下就好。

我们之前说过umask值的时候，如下：

[root@localhost ~]# umask
0022

可以看到umask值是一个4位数，后三位是我们之间讲过的基本权限（读写执行），第一位我们之前空过去了，如果忘记了，可以查看umask默认权限文章内容。

现在来说一下，第一位就是定义SetUID，SetGID，Sticky BIT，这三个特殊权限的。

还有一点，我们之前说过，普通用户是可以修改自己的密码的，但是我们查看下面两个文件，/etc/passwd文件和/etc/shadow文件。

我们知道/etc/passwd文件存放着用户的信息，/etc/shadow文件中存放着用户的密码。但是我们可以看到/etc/shadow文件的权限是000，也就是说普通用户对这个文件是没有任何操作权限的，不能看也不能打开，也不能写。

但是我们知道密码的修改，最终是要写入/etc/shadow文件中的。那用户对/etc/shadow文件没有任何权限，那怎么是把密码最终写入到/etc/shadow文件中呢。

这个奥秘就是passwd命令中，我们查看一下passwd命令。

可以看到所有者权限中，有一个标识为小s的权限，我们之前说的基本权限，读写执行分别为rwx。这个小s权限标识，就是表示该文件有SetUID特殊权限。

为什么要给passwd命令设置SetUID特殊权限？

/usr/bin/passwd命令拥有特殊权限SetUID，也就是在属主的权限位的执行权限上是小s。可以这样来理解它：当一个具有执行权限的文件设置SetUID权限后，用户执行这个文件时将以文件所有者的身份执行。/usr/bin/passwd命令具有SetUID权限，所有者为root（Linux中的命令默认所有者都是root）
也就是说当普通用户使用passwd命令，更改自己密码的时候，实际是在用passwd命令所有者root的身份在执行passwd命令，root当然可以将密码写入/etc/shadow文件（不要忘记root这个用户什么事都可以干），所以普通用户也可以修改/etc/shadow文件，命令执行完成后该身份也随之消失。
总结：passwd命令有SetUID权限，为的就是普通用户修改自己密码的时候，执行passwd命令能够修改/etc/shadow文件。

如果取消SetUID权限，则普通用户就不能修改自己的密码了。

• 小s权限标识在所有者位的时候，特殊权限位SetUID。
• 小s权限标识在所属组位的时候，特殊权限位SetGID。
• 小t权限标识在其他人位的时候，特殊权限位Sticky BIT。

2、设置SetUID

（1）只有可以执行的二进制程序（自己写的脚本也可以，只要是执行文件就行）才能设定SUID权限。

如果给非执行文件赋值SetUID，如下：

#给abc文件赋值SetUID权限
[root@localhost ~]# chmod u+s abc

# g+s是给组赋值SetGID权限，和基本权限赋值是一样的。

查看abc文件信息，如下图所示：

可以看到abc文件的所有者权限上有一个大S权限。表示abc文件没有什么作用，因为该文件不是一个可执行文件。可以理解成小s = 大s + x（执行权限）。

（2）命令执行者要对该程序拥有x（执行）权限。

查看passwd命令，普通用户对于passwd命令是属于其他人权限组里。其他人的权限中是有执行权限的。

SetUID权限是，必须是用户在执行的时候SetUID权限才生效。

（3）命令执行者在执行该程序时获得该程序文件属主的身份（在执行程序的过程中灵魂附体为文件的属主）

看上边一中的《为什么要给passwd命令设置SetUID特殊权限？》问题，有解释。

（4）SetUID权限只在该程序执行过程中有效，也就是说身份改变只在程序执行过程中有效。

（5）注意：Linux系统自带的命令赋予了特殊权限，一般没有什么问题，很安全。最危险的是自己写的脚本赋予了特殊权限，不建议手动赋予。

（6）有几点建议：

1. 关键目录应严格控制写权限。比如/、/usr等；
2. 用户的密码设置要严格遵守密码三原则；
3. 对系统中默认应该具有SetUID权限的文件作一列表，定时检查有没有这之外的文件被设置了SetUID权限。

3、检测SetUID的脚本

首先找一个全新的Linux系统，没有被人操作过。通过脚本在系统中查找含有SetUID，SetGID的文件。如果统一写入一个模板文件。

然后在定期或者不定期的执行该脚本，存入一个临时文件，然后拿这个临时文件和上面的模版文件进行对比，如果临时文件和模板文件是一样的，证明系统中没有出现新的SetUID，SetGID权限。如果有不同，则把该内容记录下来。

[root@localhost ~]# vi suidcheck.sh
#!/bin/bash
# Author：shenchao（E-mail：[email protected]）

# 搜索系统中所有拥有SUID和SGID的文件，并保存到临时目录中。
find / -perm -4000 -o -perm -2000 > /tmp/setuid.check

# 做循环，每次循环取出临时文件中的文件名
for i in $（cat /tmp/setuid.check（临时文件））
do
    grep $i/root/suid.list（模板文件） >/dev/null
        # 比对这个文件名是否在模板文件中
        if["$？"！="0"]
        # 如果在，不报错
        then
                # 如果文件名不再模板文件中，则报错。并把报错报错到日志中
                echo "$i isn't in listfile! " >> /root/suid_log_$(date +%F)

        fi

done
# 删除临时文件
rm -rf /tmp/setuid.check

以后如果我新给一个文件赋予了特殊权限

# 手工给vi加入SUID权限
[root@localhost ~]# chmod u + s /bin/vi

# 再此执行检测脚本，就会把新检测出来的特殊权限记录到一个文件中。
[root@localhost ~]# ./suidcheck.sh

# 报错了，vi不再模板文件中。代表vi被修改了SUID权限，查看文件。
[root@localhost ~]# cat suid-1og-2013-01-20
/bin/vi  isn't in listfile！

4、设置SetGID

SetGID也简称为SGID，SGID即可以针对文件生效，也可以针对目录生效，这和SUID明显不同。

（1）针对文件的作用

针对文件，SGID的含义如下：

1. 只有可执行的二进制程序才能设置SGID权限。
   同SUID。
2. 命令执行者要对该程序拥有x（执行）权限。
   同SUID。
3. 命令执行在执行程序的时候，组身份升级为该程序文件的属组。

   # 查看locate命令
   [root@localhost ~]# ll /usr/bin/locate
   -rwx-s--x 1 root slocate 35612    8月 24 2010 /usr/bin/locate
   
   # 查看mlocate.db文件
   [root@localhost ~]# ll /var/lib/mlocate/mlocate.db
   -rw-r---1 root slocate 1838850  1月 20 04：29 /var/lib/mlocate/mlocate.db
   

   当普通用户user1执行locate命令时，会发生如下事情：
   • /usr/bin/locate是可执行二进制程序，可以赋予SGID，
   • 执行命令的用户user1，对/usr/bin/locate命令拥有执行权限。
   • 执行/usr/bin/locate命令时，组身份会升级为slocate组，而slocate组对
     /var/lib/mlocate/mlocate.db数据库拥有r权限，所以普通用户可以使用locate命令查询mlocate.db数据库。
   • 命令结束，user1用户的组身份返回为user1组。
4. SetGID权限同样只在该程序执行过程中有效，也就是说组身份改变只在程序执行过程中有效。

（2）针对目录的作用

SGID针对目录设置，含义如下：

• 普通用户必须对此目录拥有r和x权限，才能进入此目录。
• 普通用户在此目录中的有效组会变成此目录的属组。
• 若普通用户对此目录拥有w权限时（也就是其他人权限是7，普通用户才能进入目录），新建的文件的默认属组是，这个目录的属组。

不明白，看下面的例子。

# 进入临时目录做此实验。因为临时目录才允许普通用户修改
[root@localhost ~]# cd /tmp/

# 建立测试目录
[root@localhost tmp]# mkdir dtest

# 给测试目录赋予SGID
[root@localhost tmp]# chmod g+s dtest

# 查看dtest/目录，SGID已经生效
[root@localhost tmp]# ll -d dtest/
drwxr-sr-x 2 root `root` 4096 1月 20 06：04 dtest/

# 给测试目录权限，让普通用户可以写，
# 注意权限一定要是777，否则普通用户进入不了目录。
[root@localhost tmp]#chmod 777 dtest/

# 切换成普通用户userl
[root@localhost tmp]# su - user1

# 普通用户进入测试目录，
# 如果上边权限不设置成777，测试普通用户进不来。
[user1@localhost ~]$ cd /tmp/dtest/

# 普通用户建立abc文件
[user1@localhost dtest]$ touch abc

# abc文件的默认属组不再是user1用户组，而变成了dtest组的属组root
[user1@localhost dtest]$ ll
总用量0
-rw-rw-r-1 userl `root` 0 1月 20 06：07 abc

总结上边例子的意思：也就是说，root用户如果给目录赋予了SGID特殊权限。那么普通用户（user1）在该文件中所创建的文件的所有组不是user1，而是这个目录的所属组。

提示：SGID针对目录的作用本身没有风险。就是赋予目录的权限是777有些风险，能不用就别用。
关于特殊权限SGID的针对目录的作用，了解一下即可。

5、Sticky BIT

Sticky BIT称之为粘着位权限，也简称为SBIT。

SBIT目前仅针对目录有效，它的作用如下：

• 粘着位目前只对目录有效。
• 普通用户对该目录拥有w和x权限（其他人位要有7权限），即普通用户可以在此目录拥有写入权限。
• 如果没有粘着位，因为普通用户拥有w权限，所以可以删除此目录下所有文件，包括其他用户建立的文件。一但赋予了粘着位，除了root可以删除所有文件，普通用户就算拥有w权限，也只能删除自己建立的文件，但是不能删除其他用户建立的文件。

说明：

• /tmp/目录就有SBIT特殊权限

  [root@localhost ~]# ll -d /tmp/
  rwxrwxrwt.4 root root 4096 2月 19 12：24 tmp
  # 看最后的其他人权限是rwt
  

• root用户在/tmp/目录创建一个abc文件

  [root@localhost tmp]# touch abc
  [root@localhost tmp]# ll
  -rw-r--r-.1 root root 0 2月 19 12：40 abc
  

• user1用户在/tmp/目录创建一个bcd文件

  [user1@localhost tmp]$ touch bcd
  [user1@localhost tmp]$ ll
  总用量0
  -rw-r--r-.1 root root 0 2月 19 12：40 abc
  -rw-rw-r-.1 userl user1 0 2月 19 12：40 bcd
  

• 用user1用户删除root用户（或者其他用户）在/tmp/目录中创建的abc文件，显示无法删除。

  [user1@localhost tmp]$ rm -rf abc
  rm：无法删除"abc"：不允许的操作
  

以上例子说的就是在一个权限是777并且有SBIT特殊权限的目录中，每个用户只能删除自己创建的文件，其他用户创建的文件我们删除不了。

6、设定文件特殊权限

特殊权限这样来表示：

• 4代表SUID
• 2代表SGID
• 1代表SBIT

举例：

# 赋予SUID权限
[root@localhost ~]# chmod 4755/u+s ftest

# 赋予SGID权限
[root@localhost ~]# chmod 2755/g+s ftest

# SBIT只对目录有效，所以建立测试目录，并赋予SBIT
[root@localhost ~]# mkdir dtest
[root@localhost ~]# chmod 1755/o+t dtest/

7、文件特殊权限：SetUID，SetGID，Sticky BIT区别

• SUID：只能针对执行程序。
• SGID：既可以针对执行文件，也可以针对目录文件。
  针对目录是没有风险的，针对执行文件和SUID是一致的，都是有风险的。
• SBIT：只能针对目录。

这些权限都是针对普通用户的。