哪位高手幫我講解一下chmod命令中的suid和guid?

ancharn

suid/sgid
  
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 而/bin/zsh是支持suid和sgid的 . perl 亦如此, 除非額外再安裝 suid-perl ....


根據(jù)現(xiàn)在的Unix機里，腳本是無法設置suid的，因為真正運行的進程是腳本的解釋程序而不是腳本本身
當然，理論上可以讓腳本的解釋程序獲得腳本的suid狀態(tài)并且動態(tài)的改變自己的suid屬性，然后在腳本運行完畢后再改回去。不過這樣的整個系統(tǒng)架構(gòu)的修改可以說不算小，而且也不符合POSIX規(guī)范（POSIX規(guī)范中沒有允許一個正在運行的進程動態(tài)修改自身的suid屬性）


由于SUID和SGID是在執(zhí)行程序（程序的可執(zhí)行位被設置）時起作用，而可執(zhí) 行位只對普通文件和目錄文件有意義，所以設置其他種類文件的SUID和SGID位是 沒有多大意義的。 首先講普通文件的SUID和SGID的作用。例子： 如果普通文件myfile是屬于foo用戶的，是可執(zhí)行的，現(xiàn)在沒設SUID位，ls命 令顯示如下： -rwxr-xr-x 1 foo staff 7734 Apr 05 17:07 myfile 任何用戶都可以執(zhí)行這個程序。UNIX的內(nèi)核是根據(jù)什么來確定一個進程對資 源的訪問權(quán)限的呢？是這個進程的運行用戶的（有效）ID，包括user id和group id。用戶可以用id命令來查到自己的或其他用戶的user id和group id。 除了一般的user id 和group id外，還有兩個稱之為effective 的id，就是 有效id，上面的四個id表示為：uid，gid，euid，egid。內(nèi)核主要是根據(jù)euid和 egid來確定進程對資源的訪問權(quán)限。 一個進程如果沒有SUID或SGID位，則euid=uid egid=gid，分別是運行這個程 序的用戶的uid和gid。例如kevin用戶的uid和gid分別為204和202，foo用戶的ui d和gid為200，201，kevin運行myfile程序形成的進程的euid=uid=204，egid=gid =202，內(nèi)核根據(jù)這些值來判斷進程對資源訪問的限制，其實就是kevin用戶對資源 訪問的權(quán)限，和foo沒關(guān)系。 如果一個程序設置了SUID，則euid和egid變成被運行的程序的所有者的uid和 gid，例如kevin用戶運行myfile，euid=200，egid=201，uid=204，gid=202，則 這個進程具有它的屬主foo的資源訪問權(quán)限。 SUID的作用就是這樣：讓本來沒有相應權(quán)限的用戶運行這個程序時，可以訪 問他沒有權(quán)限訪問的資源。passwd就是一個很鮮明的例子。 SUID的優(yōu)先級比SGID高，當一個可執(zhí)行程序設置了SUID，則SGID會自動變成 相應的egid。 下面討論一個例子： UNIX系統(tǒng)有一個/dev/kmem的設備文件，是一個字符設備文件，里面存儲了核 心程序要訪問的數(shù)據(jù)，包括用戶的口令。所以這個文件不能給一般的用戶讀寫， 權(quán)限設為：cr--r----- 1 root system 2, 1 May 25 1998 kmem 但ps等程序要讀這個文件，而ps的權(quán)限設置如下： -r-xr-sr-x 1 bin system 59346 Apr 05 1998 ps 這是一個設置了SGID的程序，而ps的用戶是bin，不是root，所以不能設置SUID來 訪問kmem，但大家注意了，bin和root都屬于system組，而且ps設置了SGID，一般 用戶執(zhí)行ps，就會獲得system組用戶的權(quán)限，而文件kmem的同組用戶的權(quán)限是可 讀，所以一般用戶執(zhí)行ps就沒問題了。但有些人說，為什么不把ps程序設置為 root用戶的程序，然后設置SUID位，不也行嗎？這的確可以解決問題，但實際中 為什么不這樣做呢？因為SGID的風險比SUID小得多，所以出于系統(tǒng)安全的考慮， 應該盡量用SGID代替SUID的程序，如果可能的話。 下面來說明一下SGID對目錄的影響。SUID對目錄沒有影響。 如果一個目錄設置了SGID位，那么如果任何一個用戶對這個目錄有寫權(quán)限的 話，他在這個目錄所建立的文件的組都會自動轉(zhuǎn)為這個目錄的屬主所在的組，而 文件所有者不變，還是屬于建立這個文件的用戶

wangying7737

zhen qiang a

yjmsx

真是不錯，一直不太明白的事終于有人說了

jiajia8218

chmod 6711 rws --s --s 文文件被設置了s u i d和g u i d，文件屬主具有讀、寫和執(zhí)行的權(quán)限，所有其他用戶具有執(zhí)行的權(quán)限
請問一下,chmod6711后應該是rws --s --x吧!

我再問一下,有沒有這個s好象沒什么區(qū)別吧?能在說的詳細點嗎?