轉換成 su 密碼認證失敗

突然發覺su不能用了,密碼絕對沒有問題,但是就是不能切換到 root 下,用 root 直接登錄卻沒有問題!?鬱悶-_-!...

通常出現這種情況,一般有下面幾種原因:

情況一:
你的用戶沒有加入wheel群組,所以su自然就有問題了,解決方法很簡單。
# usermod -G users,wheel username
# gpasswd -a username wheel
這樣你才有運行許可權。


情況二:
剛才還運行了,現在又不行了。
檢查在上次成功運行到現在為止曾經對哪些設定檔進行過修改。


情況三:
su的許可權有問題,你沒有運行的許可權。
查看su的許可權屬性
$ ls -l /bin/su

對應的許可權屬性應該是:
-rwsr-xr-x 1 root root 26928 2008-10-01 12:53 /bin/su

如果你的許可權不一樣,你可以通過下面的命令來修改:
# chown root:root /bin/su
# chmod 4755 /bin/su
經過上述方法,應該可以解決一般情況下的此類問題。

至於最後為何是4位數?趕緊 man 一下。
4000 Sets user ID on execution
2000 Sets group ID on execution
1000 Sets the link permission to directories or sets the save-text attribute for files
u+s
g+s
+t

要瞭解 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。

arrow
arrow
    全站熱搜

    BB 發表在 痞客邦 留言(0) 人氣()