前言

我们有时候在操作Linux系统的时候，往往会遇到一些奇怪的字符，例如对某一个文件/目录执行ll时，可能会出现以下情况：

[niesh@niesh ~]$ ll /usr/bin/passwd-rwsr-xr-x. 1 root root 27832 6月  10 2014 /usr/bin/passwd[niesh@niesh ~]$ ll -d /tmp/drwxrwxrwt. 15 root root 4096 7月  30 16:20 /tmp/

懵逼了，以前见到的都是 r w x，什么时候出来了s t了？这俩是啥东东？

其实，上面就是Linux文件/目录的特殊权限了 - SetUID、SetGID 和 SBIT；

呃，这仨优势啥鸟货？下面我给你慢慢解释，你们先打个照面！

SetUID

试想一个场景：

Linux普通用户可以修改自己的密码，这个是一个合情合理的设置；修改密码其实修改的是 /etc/shadow 这个文件；然而不知道你有没看过这个文件的属性：

[niesh@niesh ~]$ ll /etc/shadow----------. 1 root root 1476 7月  30 16:15 /etc/shadow

我去，bug啊？很明显普通用户对 /etc/shadow 文件没有任何权限啊，那怎么可能修改该文件呢？

一方面我们需要修改自己的密码（就是修改/etc/shadow)，另一方面这个文件对普通用户没任何权限，自相矛盾啊？这么办呢？

其实，这里就牵扯到了 SetUID 权限：修改密码的流程其实就是通过 /usr/bin/passwd 命令对 /etc/passwd进行修改，那么先让我们看一下这个可执行文件的属性：

[niesh@niesh ~]$ ll /usr/bin/passwd-rwsr-xr-x. 1 root root 27832 6月  10 2014 /usr/bin/passwd

发现/usr/bin/passwd的权限为：-rwsr-xr-x. 在此“文件所有者”的第三位是s权限，也就是咱们即将要详细讲解的的setUID权限，也就是它在作怪了！

不相信，那行，我现在验证一下（和cat命令对比）：

[niesh@niesh ~]$ passwd更改用户 niesh 的密码 。为 niesh 更改 STRESS 密码。（当前）UNIX 密码：新的 密码：[niesh@niesh ~]$ ll /usr/bin/cat-rwxr-xr-x. 1 root root 54048 11月 20 2015 /usr/bin/cat[niesh@niesh ~]$ cat /etc/shadowcat: /etc/shadow: 权限不够

SetUID(或者 s 权限）：当一个具有执行权限的文件设置SetUID权限后，用户执行这个文件时将以文件所有者的身份执行。passwd命令具有SetUID权限，所有者为root（Linux中的命令默认所有者都是root），也就是说当普通用户使用passwd更改自己密码的时候，那一瞬间突然 “灵魂附体” 了，实际在以passwd命令所有者root的身份在执行，root当然可以将密码写入/etc/shadow文件（root是一个bug的存在，在Linux中就没有它不能干的事），命令执行完成后该身份也随之消失。

0. SetUID条件：

必须具备以下几个条件（前提）：

1. 只有可执行的二进制程序才可以设置SetUID
2. 所有者必须对欲设置SetUID的文件具备 可执行(x) 权限
3. 命令执行过程中，其它用户获取所有者的身份（灵魂附体）
4. SetUID具有时间限制，即完成该程序执行后就消失（不能霸占住不放吧？）

1. 设置和取消SetUID

• 设置SetUID

  chmod 4xxx < file-name >

  chmod u+s < file-name >

• 取消SetUID

  chmod xxx < file-name >

  chmod u-s < file-name >

2. 例程

首先，查看一下touch命令的属性：

[niesh@niesh tmp]$ ll /usr/bin/touch-rwxr-xr-x. 1 root root 62432 11月 20 2015 /usr/bin/touch

然后，用普通用户创建一个文件：

[niesh@niesh tmp]$ touch test1[niesh@niesh tmp]$ ll test1-rw-rw-r--. 1 niesh niesh 0 7月  30 17:40 test1

接着，更改touch的属性，增加SetUID属性：

[niesh@niesh tmp]$ sudo chmod u+s /usr/bin/touch[sudo] password for niesh:[niesh@niesh tmp]$ ll /usr/bin/touch-rwsr-xr-x. 1 root root 62432 11月 20 2015 /usr/bin/touch

而后，用普通用户再新建一个文件：

[niesh@niesh tmp]$ touch test2

最后，查看两个新建文件的属性：

[niesh@niesh tmp]$ ll test1 test2-rw-rw-r--. 1 niesh niesh 0 7月  30 17:40 test1-rw-rw-r--. 1 root  niesh 0 7月  30 17:42 test2[niesh@niesh tmp]$

可以看到，在设置了SetUID之后，新建文件的所有者为root了，说明在执行touch的时候，用户自动升级为了所有者，灵魂附体了！

3. 危险性

设置SetUID是具备很大危险性的，例如赋予 vim 这个权限：

首先，查找vim在哪里[root@niesh ~]# whereis vimvim: /usr/bin/vim /usr/bin/vim.tiny /usr/local/bin/vim /usr/local/vim /usr/share/vim然后，查看vim的属性[root@niesh ~]# ll /usr/bin/vimlrwxrwxrwx. 1 root root 18 5月   1 21:02 /usr/bin/vim -> /usr/local/bin/vim再次，给vim增加SetUID权限[root@niesh ~]# chmod u+s /usr/bin/vim[root@niesh ~]# ll /usr/bin/vimlrwxrwxrwx. 1 root root 18 5月   1 21:02 /usr/bin/vim -> /usr/local/bin/vim最后，使用vim编辑/etc/shadow[niesh@niesh ~]# vim /etc/shadow

明显，我可以打开并进行编辑了，那万一，一个不懂的人或者而已破坏的人将自己的权限提升到了root或者干脆删除这里的内容，那后果将是灾难性的！

所以，我们需要定时查看系统中有哪些设置了SetUID权限，对不明物体进行实时打击！

SetGID

其实，SetGID基本与SetUID相同，无非也就是一个设置所有者的权限，GID为设置所属组的特殊权限！

区别点在于：SetGID也可以设置目录的相关SetGID权限！

0. SetGID条件：

• 针对文件：

  • 可执行的二进制文件
  • 命令执行者（即所属组）对该文件具备 x 权限
  • 执行时，执行者被所属组灵魂附体
  • 权限只在执行过程中有效

• 针对目录：

  • 普通用户对目录具备r和x权限，才可以进入到该目录
  • 普通用户在此目录中的有效组会变成此目录的所属组
  • 如普通用户对该目录具备w权限，新建文件的所属组为该目录的所属组

1. 设置和取消SetGID

• 设置SetGID

  chmod 2xxx

  chmod g+s

• 取消SetGID

  chmod xxx

  chmod g-s

2. 例程：

我们此处以locate命令进行讨论：

locate查询命令，比find要快很多，为什么？因为其实搜索的数据库而非整个硬盘：

[root@niesh ~]# ll /usr/bin/locate-rwx--s--x. 1 root slocate 40496 6月  10 2014 /usr/bin/locate[root@niesh ~]# ll /var/lib/mlocate/mlocate.db-rw-r-----. 1 root slocate 6306909 7月  30 19:15 /var/lib/mlocate/mlocate.db

我用普通用户进行locate查看：

[niesh@niesh root]$ locate mlocate.db/usr/share/man/man5/mlocate.db.5.gz

去掉locate的s权限：

[root@niesh ~]# chmod g-s /usr/bin/locate

[root@niesh ~]# ll /usr/bin/locate

-rwx--x--x. 1 root slocate 40496 6月 10 2014 /usr/bin/locate

[niesh@niesh root]$ locate mlocate.dblocate: 无法执行 stat () `/var/lib/mlocate/mlocate.db': 权限不够

也就是：当执行locate命令时，普通用户niesh自动升级为slocate的组成员。

SBIT

Stick Bit，粘滞位。

0.作用：

• 只对目录有效
• 普通用户对该目录有w和x权限
• 若没有粘滞位，则普通用户可以对目录下的文件/子目录进行删除操作（因为普通用户对目录具有w权限），包括其它用户建立的目录/文件；但若赋了SBIT,则普通用户只能删除自己创建的文件/目录，而不能删除不属于自己的文件/目录！

1. 设置和取消SBIT

• 设置SBIT

  chmod 1xxx < dir-name >

  chmod o+t < dir-name >

• 取消SBIT

  chmod xxx < dir-name >

  chmod o-t < dir-name >

2. 例程

以/tmp为例：

查看/tmp的权限：

[niesh@niesh tmp]$ ll -d /tmp/

drwxrwxrwt. 8 root root 4096 7月 30 19:40 /tmp/

会看到，/tmp目录的权限other部分为rwt,这个t就是我们设置的粘滞位

接下来，我们用其它用户创建两个文件：

[Jimmy@niesh tmp]$ touch test-file[Jimmy@niesh tmp]$ mkdir test-dir[Jimmy@niesh tmp]$ ll总用量 0drwxrwxr-x. 2 Jimmy Jimmy 6 7月  30 19:44 test-dir-rw-rw-r--. 1 root  Jimmy 0 7月  30 19:44 test-file

切换到另外一个用户niesh:

[niesh@niesh tmp]$ ll总用量 0drwxrwxr-x. 2 Jimmy Jimmy 6 7月  30 19:44 test-dir-rw-rw-r--. 1 root  Jimmy 0 7月  30 19:44 test-file

在 niesh用户下，删除/tmp目录下的文件：

[niesh@niesh tmp]$ rm -rf test-dir/ test-filerm: 无法删除"test-dir/": 不允许的操作

无法删除！

然后，我们切换到root，去掉/tmp的粘滞位：

[niesh@niesh tmp]$ su -密码：上一次登录：日 7月 30 19:43:21 CST 2017pts/0 上[root@niesh ~]# chmod o-t /tmp/[root@niesh ~]# ll -d /tmp/drwxrwxrwx. 9 root root 4096 7月  30 19:48 /tmp/

最后，切换到普通用户niesh，再次删除/tmp下的文件：

[niesh@niesh root]$ rm -rf /tmp/test-dir/ /tmp/test-file[niesh@niesh root]$ ll /tmp/总用量 0