Linux系統UID和GID詳解

 Linux系統UID和GID詳解

　　一個檔案都有一個所有者, 表示該檔案是誰建立的. 同時, 該檔案還有一個組編號, 表示該檔案所屬的組, 一般為檔案所有者所屬的組.
　　如果是一個可執行檔, 那麼在執行時, 一般該檔案只擁有調用該檔案的使用者具有的許可權. 而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)

　　要刪除一個檔案，你不一定要有這個檔案的寫入權限，但你一定要有這個檔案的上級目錄的寫入權限。也就是說，你即使沒有一個檔案的寫入權限，但你有這個檔案的上級目錄的寫入權限，你也可以把這個檔案給刪除，而如果沒有一個目錄的寫入權限，也就不能在這個目錄下建立檔案。
　　如何才能使一個目錄既可以讓任何使用者寫入檔案，又不讓使用者刪除這個目錄下他人的檔案，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