转自: http://www.cnblogs.com/Jimmy1988/p/7260215.html
前言
我们有时候在操作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权限,也就是它在作怪了!
SetUID(或者 s 权限):当一个具有执行权限的文件设置SetUID权限后,用户执行这个文件时将以文件所有者的身份执行。passwd命令具有SetUID权限,所有者为root(Linux中的命令默认所有者都是root),也就是说当普通用户使用passwd更改自己密码的时候,那一瞬间突然 “灵魂附体” 了,实际在以passwd命令所有者root的身份在执行,root当然可以将密码写入/etc/shadow文件(root是一个bug的存在,在Linux中就没有它不能干的事),命令执行完成后该身份也随之消失。
0. SetUID条件:
必须具备以下几个条件(前提):
- 只有可执行的二进制程序才可以设置SetUID
- 所有者必须对欲设置SetUID的文件具备 可执行(x) 权限
- 命令执行过程中,其它用户获取所有者的身份(灵魂附体)
- SetUID具有时间限制,即完成该程序执行后就消失(不能霸占住不放吧?)
1. 设置和取消SetUID
设置SetUID
chmod 4xxx < file-name > chmod u+s < file-name >
取消SetUID
chmod xxx < file-name > chmod u-s < file-name >
SetGID
其实,SetGID基本与SetUID相同,无非也就是一个设置所有者的权限,GID为设置所属组的特殊权限! 区别点在于:SetGID也可以设置目录的相关SetGID权限!
0. SetGID条件:
-
针对文件:
- 可执行的二进制文件
- 命令执行者(即所属组)对该文件具备 x 权限
- 执行时,执行者被所属组灵魂附体
- 权限只在执行过程中有效
-
针对目录:
- 普通用户对目录具备
r
和x
权限,才可以进入到该目录 - 普通用户在此目录中的有效组会变成此目录的所属组
- 如普通用户对该目录具备
w
权限,新建文件的所属组为该目录的所属组
- 普通用户对目录具备
1. 设置和取消SetGID
设置SetGID
chmod 2xxx
取消SetGID
chmod xxx
我用普通用户进行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.db locate: 无法执行 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
总用量 0 drwxrwxr-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
总用量 0
drwxrwxr-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-file rm: 无法删除"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