亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標題: 請問suid的問題 [打印本頁]

作者: aQua99 時間: 2004-08-05 16:21
標題: 請問suid的問題
一個要有root權限才能執(zhí)行腳本,如何讓普通用戶執(zhí)行
我試了chmod 6755 xx 后不行?

作者: bjgirl 時間: 2004-08-05 16:39
標題: 請問suid的問題
sudo
or
chmod +s command

作者: aQua99 時間: 2004-08-05 17:14
標題: 請問suid的問題

原帖由 "bjgirl" 發(fā)表：
sudo
or
chmod +s command

書上說某些系統(tǒng)因為安全原因不支持suid/sgid,設置了也白設,不知道是不是包括sco openserver...
chmod +s command或者chmod 6755 command后,
文件屬性 -rwsr-sr-x
其它用戶執(zhí)行仍然報錯

請問sudo是說先su后do么?那怎么寫到腳本中去?
還是說有sudo這個命令?sco好像沒有

作者: wenuy 時間: 2004-08-05 17:54
標題: 請問suid的問題
chmod a+s * -R
無敵
什么人都能用了

作者: aQua99 時間: 2004-08-05 18:27
標題: 請問suid的問題

原帖由 "wenuy" 發(fā)表：
chmod a+s * -R
無敵
什么人都能用了

??
chmod a+s command與chmod +s command 沒有區(qū)別吧
-R是什么意思?會被認為是一個文件的

作者: bjgirl 時間: 2004-08-05 20:00
標題: 請問suid的問題

原帖由 "wenuy" 發(fā)表：
chmod a+s * -R
無敵
什么人都能用了

Really

作者: aQua99 時間: 2004-08-05 22:30
標題: 請問suid的問題
oh,我自己搞錯了
腳本中需要權限的命令是ipcrm
改腳本的suid是沒用的
關鍵是chmod +s ipcrm

bjgirl說話太精煉了,把chmod +s xx改成了chmod +s command
指出了問題所在,卻不肯再說的明白一些...

作者: 網中人 時間: 2004-08-06 00:15
標題: 請問suid的問題
呵呵~~~ 若帶 suid 的 command 是個木馬或病毒, 那就好玩了... ^_^

作者: bjgirl 時間: 2004-08-06 00:27
標題: 請問suid的問題
[quote]原帖由 "網中人"]呵呵~~~ 若帶 suid 的 command 是個木馬或病毒, 那就好玩了... ^_^[/quote 發(fā)表：

嗯,是呀,還是請netman講講怎么預防這些潛在的危機吧

謝謝 !

btw:順便給介紹一下shell方面應該注意的一些安全知識! 再次感謝!(如時間寬裕的情況下)

作者: 網中人 時間: 2004-08-07 02:07
標題: 請問suid的問題
要了解 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 ....

碰到安全問題, 每一個系統(tǒng)使用者(尤其是管理員)都應小心慎重對待.
或以一句話來總結的話, 就是:
--- 勿以善小而不為, 勿以惡小而為之!

p.s.
以上, 我還沒提到 suid/sgid 對 directory 的作用.
有空再補充吧.

作者: bjgirl 時間: 2004-08-07 12:00
標題: 請問suid的問題
謝謝,

作者: torrent 時間: 2004-08-07 12:03
標題: 請問suid的問題
不錯啊，可以作為精華貼

作者: heusun 時間: 2004-08-31 17:51
標題: 請問suid的問題
brief and clear !

作者: 我愛臭豆腐 時間: 2004-09-04 08:46
標題: 請問suid的問題

原帖由 "網中人" 發(fā)表：
要了解 suid/sgid, 必需先了解 process 及 permission.
我們需知道: 每個 process 都有其 effective uid/gid , 以決定其在傳統(tǒng) unix filesystem 中獲得的實際 permission .
再, process 是由 binary 產生的, 而 bi..........

好東西

作者: murdoc 時間: 2005-11-03 19:10
網中人兄的話，使我收益非淺，不過有些還是不太理解，我自己理解理解吧，不會的再請教

作者: ancharn 時間: 2006-02-10 14:42
bash shell script 在先天上不支援 suid/sgid 而/bin/zsh是支持suid和sgid的 . perl 亦如此, 除非額外再安裝 suid-perl ....

作者: ancharn 時間: 2006-02-10 15:08
suid/sgid

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

根據(jù)現(xiàn)在的Unix機里，腳本是無法設置suid的，因為真正運行的進程是腳本的解釋程序而不是腳本本身
當然，理論上可以讓腳本的解釋程序獲得腳本的suid狀態(tài)并且動態(tài)的改變自己的suid屬性，然后在腳本運行完畢后再改回去。不過這樣的整個系統(tǒng)架構的修改可以說不算小，而且也不符合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的內核是根據(jù)什么來確定一個進程對資源的訪問權限的呢？是這個進程的運行用戶的（有效）ID，包括user id和group id。用戶可以用id命令來查到自己的或其他用戶的user id和group id。除了一般的user id 和group id外，還有兩個稱之為effective 的id，就是有效id，上面的四個id表示為：uid，gid，euid，egid。內核主要是根據(jù)euid和 egid來確定進程對資源的訪問權限。一個進程如果沒有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，內核根據(jù)這些值來判斷進程對資源訪問的限制，其實就是kevin用戶對資源訪問的權限，和foo沒關系。如果一個程序設置了SUID，則euid和egid變成被運行的程序的所有者的uid和 gid，例如kevin用戶運行myfile，euid=200，egid=201，uid=204，gid=202，則這個進程具有它的屬主foo的資源訪問權限。 SUID的作用就是這樣：讓本來沒有相應權限的用戶運行這個程序時，可以訪問他沒有權限訪問的資源。passwd就是一個很鮮明的例子。 SUID的優(yōu)先級比SGID高，當一個可執(zhí)行程序設置了SUID，則SGID會自動變成相應的egid。下面討論一個例子： UNIX系統(tǒng)有一個/dev/kmem的設備文件，是一個字符設備文件，里面存儲了核心程序要訪問的數(shù)據(jù)，包括用戶的口令。所以這個文件不能給一般的用戶讀寫，權限設為：cr--r----- 1 root system 2, 1 May 25 1998 kmem 但ps等程序要讀這個文件，而ps的權限設置如下： -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組用戶的權限，而文件kmem的同組用戶的權限是可讀，所以一般用戶執(zhí)行ps就沒問題了。但有些人說，為什么不把ps程序設置為 root用戶的程序，然后設置SUID位，不也行嗎？這的確可以解決問題，但實際中為什么不這樣做呢？因為SGID的風險比SUID小得多，所以出于系統(tǒng)安全的考慮，應該盡量用SGID代替SUID的程序，如果可能的話。下面來說明一下SGID對目錄的影響。SUID對目錄沒有影響。如果一個目錄設置了SGID位，那么如果任何一個用戶對這個目錄有寫權限的話，他在這個目錄所建立的文件的組都會自動轉為這個目錄的屬主所在的組，而文件所有者不變，還是屬于建立這個文件的用戶

歡迎光臨 Chinaunix (http://www.72891.cn/)