Linux系統(tǒng)UID和GID介紹
一個文件都有一個所有者, 表示該文件是誰創(chuàng)建的. 同時, 該文件還有一個組編號, 表示該文件所屬的組, 一般為文件所有者所屬的組.
如果是一個可執(zhí)行文件, 那么在執(zhí)行時, 一般該文件只擁有調用該文件的用戶具有的權限. 而setuid, setgid 可以來改變這種設置.
setuid: 設置使文件在執(zhí)行階段具有文件所有者的權限. 典型的文件是 /usr/bin/passwd. 如果一般用戶執(zhí)行該文件, 則在執(zhí)行過程中, 該文件可以獲得root權限, 從而可以更改用戶的密碼.
setgid: 該權限只對目錄有效. 目錄被設置該位后, 任何用戶在此目錄下創(chuàng)建的文件都具有和該目錄所屬的組相同的組.
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) 采用八進制方式. 對一般文件通過三組八進制數(shù)字來置標志, 如 666, 777, 644等. 如果設置這些特殊標志, 則在這組數(shù)字之外外加一組八進制數(shù)字. 如 4666, 2777等. 這一組八進制數(shù)字三位的意義如下:
abc
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)
要刪除一個文件,你不一定要有這個文件的寫權限,但你一定要有這個文件的上級目錄的寫權限。也就是說,你即使沒有一個文件的寫權限,但你有這個文件的上級目錄的寫權限,你也可以把這個文件給刪除,而如果沒有一個目錄的寫權限,也就不能在這個目錄下創(chuàng)建文件。
如何才能使一個目錄既可以讓任何用戶寫入文件,又不讓用戶刪除這個目錄下他人的文件,sticky就是能起到這個作用。stciky一般只用在目錄上,用在文件上起不到什么作用。
在一個目錄上設了sticky位后,(如/tmp,權限為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 產生的, 而 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 的有與無將導致什么不同結果?
好了, 由于 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后
(-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發(fā)生讀,寫,執(zhí)行文件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
關鍵詞:Linux
閱讀本文后您有什么感想? 已有 人給出評價!
- 0
- 0
- 0
- 0
- 0
- 0