一个文件都有一个所有者, 表示该文件是谁创建的. 同时, 该文件还有一个组编号, 表示该文件所属的组, 一般为文件所有者所属的组. 如果是一个可执行文件, 那么在执行时, 一般该文件只拥有调用该文件的用户具有的权限. 而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等. 这一组八进制数字三位的意义如下, abc 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)
这三个权限的数字位可以这么理解 [root@server3 test]# 1 1 1 [root@server3 test]# rw s rws rwt [root@server3 test]# [root@server3 test]# SUID SGID Sticky 所以，可以得出 chmod 4777是设sid chmod 2777是设置gid chmod 1777是设sticky 常用操作 找出所有危险的目录（设置目录所有人可读写却没有设置sticky位的目录） find / -perm -0007 -type d 找出所有设置了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后 (-r-s--x--x) 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
扫一扫
780
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
