set uid，set gid，sticky bit詳解

ddvv

一個文件都有一個所有者, 表示該文件是誰創(chuàng)建的. 同時, 該文件還有一個組編號,
表示該文件所屬的組, 一般為文件所有者所屬的組.  如果是一個可執(zhí)行文件, 那么在執(zhí)行時, 一般該文件只擁有調(diào)用該文件的用戶具有的權(quán)限.
而setuid, setgid 可以來改變這種設置.
setuid: 設置使文件在執(zhí)行階段具有文件所有者的權(quán)限. 典型的文件是 /usr/bin/passwd. 如果一般用戶執(zhí)行該文件, 則在執(zhí)行過程中, 該文件可以獲得root權(quán)限, 從而可以更改用戶的密碼.
setgid: 該權(quán)限只對目錄有效. 目錄被設置該位后, 任何用戶在此目錄下創(chuàng)建的文件都具有和該目錄所屬的組相同的組.
sticky bit: 該位可以理解為防刪除位. 一個文件是否可以被某用戶刪除,
主要取決于該文件所屬的組是否對該用戶具有寫權(quán)限. 如果沒有寫權(quán)限, 則這個目錄下的所有文件都不能被刪除, 同時也不能添加新的文件.
如果希望用戶能夠添加文件但同時不能刪除文件, 則可以對文件使用sticky bit位. 設置該位后, 就算用戶對目錄具有寫權(quán)限,
也不能刪除該文件.
下面說一下如何操作這些標志: 操作這些標志與操作文件權(quán)限的命令是一樣的, 都是 chmod. 有兩種方法來操作,
1）
chmod u+s temp -- 為temp文件加上setuid標志. (setuid 只對文件有效)
chmod g+s tempdir -- 為tempdir目錄加上setgid標志 (setgid 只對目錄有效)
chmod o+t temp -- 為temp文件加上sticky標志 (sticky只對文件有效)
2) 采用八進制方式. 對一般文件通過三組八進制數(shù)字來置標志, 如 666, 777, 644等. 如果設置這些特殊標志, 則在這組數(shù)字之外外加一組八進制數(shù)字. 如 4666, 2777等. 這一組八進制數(shù)字三位的意義如下,
a - setuid位, 如果該位為1, 則表示設置setuid
b - setgid位, 如果該位為1, 則表示設置setgid
c - sticky位, 如果該位為1, 則表示設置sticky
設置完這些標志后, 可以用 ls -l 來查看. 如果有這些標志, 則會在原來的執(zhí)行標志位置上顯示. 如
rwsrw-r-- 表示有setuid標志
rwxrwsrw- 表示有setgid標志
rwxrw-rwt 表示有sticky標志
那么原來的執(zhí)行標志x到哪里去了呢? 系統(tǒng)是這樣規(guī)定的, 如果本來在該位上有x, 則這些特殊標志顯示為小寫字母 (s, s, t). 否則, 顯示為大寫字母 (S, S, T)
這三個權(quán)限的數(shù)字位可以這么理解：在原來的三位權(quán)限位前增設一位，表示強制位和冒險位。與原來一樣，該位取值亦用加法運算。如，同時設定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
要刪除一個文件，你不一定要有這個文件的寫權(quán)限，但你一定要有這個文件的上級目錄的寫權(quán)限。也就是說，你即使沒有一個文件的寫權(quán)限，但你有這個文件的上級目錄的寫權(quán)限，你也可以把這個文件給刪除，而如果沒有一個目錄的寫權(quán)限，也就不能在這個目錄下創(chuàng)建文件。
如何才能使一個目錄既可以讓任何用戶寫入文件，又不讓用戶刪除這個目錄下他人的文件，sticky就是能起到這個作用。stciky一般只用在目錄上，用在文件上起不到什么作用。
在一個目錄上設了sticky位后，（如/tmp，權(quán)限為1777)所有的用戶都可以在這個
目錄下創(chuàng)建文件，但只能刪除自己創(chuàng)建的文件，這就對所有用戶能寫的目錄下的用戶文件啟到了保護的作用。（我當時/tmp沒有設sticky位，而在文件上
設了，這也就是為什么我為什么設了sticky位，還能刪除自己創(chuàng)建的文件的原因了）
----------------------------------------------------------------------------------------------------------------------
suid/sgid
要了解 suid/sgid, 必需先了解 process 及 permission.
我們需知道: 每個 process 都有其 effective uid/gid ,
以決定其在傳統(tǒng) unix filesystem 中獲得的實際 permission . 再, process 是由 binary 產(chǎn)生的, 而
binary 是從 shell / shell script. 加載執(zhí)行.
在正常的情況下, process 的 effective uid/gid 是從 parent 繼承, 或簡單說是與 shell 的 uid/gid 一樣. shell 的 uid/gid 則是跟據(jù) /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 執(zhí)行這個 prog1 的話, 那
effective uid/gid 就是 500 ... 但若 prog1 設了 suid/sgid 后, 那其 effective
uid/gid 就是 root !
一旦這個 process effective 是 root 的話, 那它對 file system 的 permission 就如脫韁野馬般任意奔騰而不受限制了.
因此我才在前面提到木馬程序與病毒的例子...
試想一下: 若病毒的 user/group 被設為 root, 然后被一般user執(zhí)行時, suid/sgid 的有與無將導致甚么不同結(jié)果?
好了, 由于 suid/sgid 在系統(tǒng)上有其存在的必要性(舉 /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權(quán)利，因為設置了suid，所以fork出來的進程(passwd.process)的euid=文件(passwd)的owner的uid 也就是
passwd.process.euid=passwd.owner.uid=0
euid和guid是用來進程passwd.process發(fā)生讀，寫，執(zhí)行文件shadow的時候確認訪問權(quán)限的
-r--------  1 root root 855 Sep  4 10:58 /etc/shadow( passwd.uid=0 有r權(quán)限）
文件shadow.owner.uid為0擁有r權(quán)限  因為passwd.process.euid=shadow.ower.uid=0所以由test用戶產(chǎn)生的進程passwd.process擁有文件shadow的r權(quán)限,
-r-s--x--x  1 root root 19336 Sep  7  2004 /usr/bin/passwd
               
               
               

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