set uid，set gid，sticky bit详解

一个文件都有一个所有者, 表示该文件是谁创建的. 同时, 该文件还有一个组编号, 表示该文件所属的组, 一般为文件所有者所属的组. 如果是一个可执行文件, 那么在执行时, 一般该文件只拥有调用该文件的用户具有的权限. 而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