set uid，set gid，sticky bit详解

ddvv

一个文件都有一个所有者, 表示该文件是谁创建的. 同时, 该文件还有一个组编号,
表示该文件所属的组, 一般为文件所有者所属的组.  如果是一个可执行文件, 那么在执行时, 一般该文件只拥有调用该文件的用户具有的权限.
而setuid, setgid 可以来改变这种设置.
setuid: 设置使文件在执行阶段具有文件所有者的权限. 典型的文件是 /usr/bin/passwd. 如果一般用户执行该文件, 则在执行过程中, 该文件可以获得root权限, 从而可以更改用户的密码.
setgid: 该权限只对目录有效. 目录被设置该位后, 任何用户在此目录下创建的文件都具有和该目录所属的组相同的组.
sticky bit: 该位可以理解为防删除位. 一个文件是否可以被某用户删除,
主要取决于该文件所属的组是否对该用户具有写权限. 如果没有写权限, 则这个目录下的所有文件都不能被删除, 同时也不能添加新的文件.
如果希望用户能够添加文件但同时不能删除文件, 则可以对文件使用sticky bit位. 设置该位后, 就算用户对目录具有写权限,
也不能删除该文件.
下面说一下如何操作这些标志: 操作这些标志与操作文件权限的命令是一样的, 都是 chmod. 有两种方法来操作,
1）
chmod u+s temp -- 为temp文件加上setuid标志. (setuid 只对文件有效)
chmod g+s tempdir -- 为tempdir目录加上setgid标志 (setgid 只对目录有效)
chmod o+t temp -- 为temp文件加上sticky标志 (sticky只对文件有效)
2) 采用八进制方式. 对一般文件通过三组八进制数字来置标志, 如 666, 777, 644等. 如果设置这些特殊标志, 则在这组数字之外外加一组八进制数字. 如 4666, 2777等. 这一组八进制数字三位的意义如下,
a - setuid位, 如果该位为1, 则表示设置setuid
b - setgid位, 如果该位为1, 则表示设置setgid
c - sticky位, 如果该位为1, 则表示设置sticky
设置完这些标志后, 可以用 ls -l 来查看. 如果有这些标志, 则会在原来的执行标志位置上显示. 如
rwsrw-r-- 表示有setuid标志
rwxrwsrw- 表示有setgid标志
rwxrw-rwt 表示有sticky标志
那么原来的执行标志x到哪里去了呢? 系统是这样规定的, 如果本来在该位上有x, 则这些特殊标志显示为小写字母 (s, s, t). 否则, 显示为大写字母 (S, S, T)
这三个权限的数字位可以这么理解：在原来的三位权限位前增设一位，表示强制位和冒险位。与原来一样，该位取值亦用加法运算。如，同时设定sid和gid，该位为6.
所以，可以得出
chmod 4777是设sid，user为7，group为7，other为7
chmod 2777是设置gid，user为7，group为7，other为7
chmod 1777是设sticky，user为7，group为7，other为7
常用操作：
1、找出所有危险的目录（设置目录所有人可读写却没有设置sticky位的目录）
find / -perm -0007 -type d
2、找出所有设置了suid的文件
find / -perm -4000 -type f
要删除一个文件，你不一定要有这个文件的写权限，但你一定要有这个文件的上级目录的写权限。也就是说，你即使没有一个文件的写权限，但你有这个文件的上级目录的写权限，你也可以把这个文件给删除，而如果没有一个目录的写权限，也就不能在这个目录下创建文件。
如何才能使一个目录既可以让任何用户写入文件，又不让用户删除这个目录下他人的文件，sticky就是能起到这个作用。stciky一般只用在目录上，用在文件上起不到什么作用。
在一个目录上设了sticky位后，（如/tmp，权限为1777)所有的用户都可以在这个
目录下创建文件，但只能删除自己创建的文件，这就对所有用户能写的目录下的用户文件启到了保护的作用。（我当时/tmp没有设sticky位，而在文件上
设了，这也就是为什么我为什么设了sticky位，还能删除自己创建的文件的原因了）
----------------------------------------------------------------------------------------------------------------------
suid/sgid
要了解 suid/sgid, 必需先了解 process 及 permission.
我们需知道: 每个 process 都有其 effective uid/gid ,
以决定其在传统 unix filesystem 中获得的实际 permission . 再, process 是由 binary 产生的, 而
binary 是从 shell / shell script. 加载执行.
在正常的情况下, process 的 effective uid/gid 是从 parent 继承, 或简单说是与 shell 的 uid/gid 一样. shell 的 uid/gid 则是跟据 /etc/passwd 的第 3 与 第 4 字段决定.
当我们有了以上的概念之后, 再来看 suid 对 effective uid/gid 的影响：若 binary file 带有 suid/sgid 的时候,
其 effective id 就不是从 parent 那边继承, 而是以 binary file 本身的 user/group 为准.
举例而言, 若一个 prog1 的 user/group 都是 root , 但没设
suid/sgid ,  那当一个 uid(500)/gid(500) 的 parent process 执行这个 prog1 的话, 那
effective uid/gid 就是 500 ... 但若 prog1 设了 suid/sgid 后, 那其 effective
uid/gid 就是 root !
一旦这个 process effective 是 root 的话, 那它对 file system 的 permission 就如脱缰野马般任意奔腾而不受限制了.
因此我才在前面提到木马程序与病毒的例子...
试想一下: 若病毒的 user/group 被设为 root, 然后被一般user执行时, suid/sgid 的有与无将导致甚么不同结果?
好了, 由于 suid/sgid 在系统上有其存在的必要性(举 /usr/bin/passwd 与 /etc/shadow 为例), 但同时又有极大的杀伤力, 在应用上要异常小心!
因此, bash shell script. 在先天上不支援 suid/sgid . perl 亦如此, 除非额外再安装 suid-perl ....
                       uid      gid   euid   egid
root                   0        0                              
test                   500      500                              
tset.shell             500      500   500    500     登陆后的shell
test.passwd.process    500      500   0      500     fork后
test用户fork binary文件passwd后，test属于others，拥有该文件的x权利，因为设置了suid，所以fork出来的进程(passwd.process)的euid=文件(passwd)的owner的uid 也就是
passwd.process.euid=passwd.owner.uid=0
euid和guid是用来进程passwd.process发生读，写，执行文件shadow的时候确认访问权限的
-r--------  1 root root 855 Sep  4 10:58 /etc/shadow( passwd.uid=0 有r权限）
文件shadow.owner.uid为0拥有r权限  因为passwd.process.euid=shadow.ower.uid=0所以由test用户产生的进程passwd.process拥有文件shadow的r权限,
-r-s--x--x  1 root root 19336 Sep  7  2004 /usr/bin/passwd
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/49093/showart_2043155.html