在Linux系統中每個普通使用者都可以更改自己的密碼，這是合理的設定。
問題是：使用者的資訊儲存在檔案/etc/passwd中，使用者的密碼儲存在檔案/etc/shadow中，也就是說使用者更改自己密碼時是修改了/etc/shadow檔案中的加密密碼，但是，
-rw-r--r-- 1 root root 1787 Oct 27  2009 /etc/passwd
-r-------- 1 root root 1187 Oct 27  2009 /etc/shadow
/etc/passwd檔案每個使用者都有讀許可權但是隻有root有寫許可權，/etc/shadow檔案只有超級使用者root有讀寫許可權，也就是說普通使用者對這兩個檔案都沒有寫許可權無法寫入新密碼，為什麼普通使用者可以更改密碼呢？


PS：在Linux中設定或更改使用者密碼，是先寫入到/etc/passwd檔案然後通過pwconv命令轉換到/etc/shadow檔案，執行pwunconv命令可觀察到轉換前效果，會觀察到/etc/shadow檔案神奇的消失掉了，而/etc/passwd檔案中原來打x的地方變成了真正的加密密碼。
 
其實，使用者能更改密碼真正的祕密不在於檔案的許可權，而在於更改密碼的命令passwd 。
-rwsr-xr-x 1 root root 22960 Jul 17  2006 /usr/bin/passwd
passwd命令有一個特殊的許可權標記s ，存在於檔案所有者的許可權位上。這是一類特殊的許可權SetUID ，可以這樣來理解它：當一個具有執行許可權的檔案設定SetUID許可權後，使用者執行這個檔案時將以檔案所有者的身份執行。passwd命令具有SetUID許可權，所有者為root（Linux中的命令預設所有者都是root），也就是說當普通使用者使用passwd更改自己密碼的時候，那一瞬間突然靈魂附體了，實際在以passwd命令所有者root的身份在執行，root當然可以將密碼寫入/etc/shadow檔案（不要忘記root這個傢伙是superuser什麼事都可以幹），命令執行完成後該身份也隨之消失。
 
可以試驗用root身份修改passwd命令許可權去掉SetUID ：
chmod u-s /usr/bin/passwd
再嘗試以普通使用者身份登入後修改密碼，就會發現提示：
passwd
Changing password for user samlee.
Changing password for samlee
(current) UNIX password:
passwd: Authentication token manipulation error
普通使用者無法修改密碼，所以只要能夠想明白為什麼普通使用者可以更改密碼就可以大概瞭解SetUID許可權的作用。
 
接下來我們用兩個SetUID的按理來進一步詮釋下它的概念——

 
案例一：SetUID授權示例
 
為便於深入理解SetUID ，筆者以touch命令為例做一演示。
普通使用者samlee用touch建立檔案newfile01 ：
touch newfile01
ls -l newfile01
-rw-rw-r-- 1 samlee samlee 0 05-21 01:20 newfile01
檔案的建立者預設就是所有者，所以檔案newfile01的所有者為samlee 。
管理員root給touch命令新增SetUID許可權：
chmod u+s /bin/touch   # 或 chmod 4755 /bin/touch
ls -l /bin/touch
-rwsr-xr-x 1 root root 42284 Jul 13  2009 /bin/touch
再用普通使用者samlee建立檔案newfile02，看到如下結果：
touch newfile02
ls -l newfile02
-rw-rw-r-- 1 root samlee 0 05-21 01:48 newfile02
通過這個例子，我們可以再詮釋下SetUID的定義，當一個可執行檔案（命令touch）設定SetUID許可權後，當普通使用者samlee執行touch建立新檔案時，實際上是以touch命令所有者root的身份在執行此操作，既然是以root身份執行，當然新建檔案的所有者為root ，這就是SetUID的作用。
 
再看一下與SetUID類似的SetGID許可權，看一個例子，給touch命令再授予SetGID ：
chmod g+s /bin/touch   # 或 chmod 6755 /bin/touch
ls -l /bin/touch
-rwsr-sr-x 1 root root 42284 Jul 13  2009 /bin/touch
此時，再使用touch建立新檔案newfile03，會看到如下現象：
touch newfile03
ls -l newfile03
-rw-rw-r-- 1 root root 0 05-21 01:48 newfile02
新建檔案的所屬組為touch命令的所屬組，而不是執行touch命令的普通使用者samlee的所屬組，這就是SetGID的作用，與SetUID類似，使用者在執行具有SetGID的命令時會呼叫命令所屬組的身份。
 
案例二：危險的SetUID
 
對於SetUID的使用，可以做一個的比喻：一個絕密機關，要讓一些人進來做一些事情，但是不能讓他們看見機關內部的情況，於是授權一些特殊的“車輛”（沒有窗戶，車門緊閉，看不到外面，只有一個小洞允許乘坐的人伸出手臂做事），帶著所乘坐的人開到要去的地方，允許它辦完事情馬上帶他出來。這樣是不是很安全？不一定。如果“車輛”沒有經過精挑細選，可能有很多“門窗”，那可就危險了，這種類似的場景相信大家在一些警匪電影中已經見過多次了。
普通使用者使用vi編輯/etc/shadow檔案會提示“PermissionDenied”，這是合理的設定，但是如果賦予vi以SetUID許可權：
    chmod u+s /bin/vi
ls -l /bin/vi
-rwsr-xr-x 1 root root 594740 Jun 12  2009 /bin/vi
此時，普通使用者使用vi即可以編輯/etc/shadow檔案，因為具備root身份，可以進行任意讀寫操作（比如可以把任何一個使用者密碼位清空，則使用者登入不需要輸入密碼）。但是使用more、cat等命令仍然無法檢視檔案/etc/shadow的內容，只有被授予了SetUID的vi可以檢視和修改。同樣，vi如果具有了SetUID許可權，普通使用者可以vi編輯/etc/passwd檔案把自己的UID改為0 ，則他的許可權就和root一樣；可以vi編輯/etc/inittab檔案把預設執行級別改成6 ，則Linux會開機後不停的重啟……
 
再來看一個令人不安的情況，用普通使用者嘗試關閉Apache服務： 
     ps -le | grephttpd
140 S     0  8916     1  0  76   0    -  3697 -      ?        00:00:00 httpd
kill 8916
-bash: kill: (8916) - Operation not permitted
可以看到，普通使用者不可以關閉root啟動的程序，但是如果做下面一個動作：
chmod 6555 /bin/kill
現在當普通使用者執行kill時，因為kill被授予了SetUID許可權，在執行的一瞬間具有了root許可權，只要使用者不爽想關閉任何服務都可以！
 
所以，SetUID許可權不能隨便設定，同時要防止黑客的惡意修改，怎樣避免SetUID的不安全影響，有幾點建議： 
    1. 關鍵目錄應嚴格控制寫許可權。比如“/”、“/usr”等； 
    2. 使用者的密碼設定要足夠強壯，8位以上，大小寫字母、數字、符號的組合，如：[email protected]，且定期更換；
    3. 對系統中應該具有SetUID許可權的檔案作一列表，定時檢查有沒有這之外的檔案被設定了SetUID許可權。
 
可以對系統中應該具有SetUID許可權的檔案作一列表，定時檢查有沒有非列表中的命令被設定了SetUID許可權。 
    在Linux安裝部署完成後，執行下面命令生成SetUID列表檔案：
mkdir /script   # 建立目錄/script
find / -perm -4000 -o -perm -2000 >/script/setuid.list   
命令find選項“-perm”為指定檔案許可權，SetUID許可權位對應數字標識為4 ，SetGID許可權位對應數字標識為2 ，後面寫為“000”標識對所有者所屬組其他人三類使用者的許可權不限制；“-o”表示or，就是檔案具有SetUID或者具有SetGID都在搜尋之列，生成的搜尋結果存放在檔案/script/setuid.list中。
 
在需要對系統做檢查時，執行以下shell程式。也可以放在計劃任務中定時檢查。
/usr/bin/find / -perm -4000 -o -perm -2000 >/tmp/setuid.check
for file in `/bin/cat /tmp/setuid.check`
do
        /bin/grep $file /script/setuid.list > /dev/null
               if [ "$?" != "0" ]
               then
                      echo "$file isn't in list! it's danger!!"
               fi
done
/bin/rm /tmp/setuid.check
假設命令kill被設定了SetUID ，則會檢測提示：
/bin/kill isn't in list! it's danger!!
 
另外，如果在一些資料存放的分割槽想禁用SetUID功能，還可以做如下設定，編輯配置檔案/etc/fstab ，找到要設定的分割槽（如/home）所對應的設定行：
vi /etc/fstab
LABEL=/home       /home     ext3        defaults          1     2
在設定“defaults”後，新增“nosuid”選項，並重新掛載/home分割槽：
vi /etc/fstab
LABEL=/home       /home     ext3        defaults,nosuid              1     2
mount -o remount /home
設定後，分割槽/home上任何可執行檔案即使被設定了SetUID許可權也無法執行（讀者可自行拷貝一個SetUID命令至/home目錄下執行試驗），在一些存放資料、用來備份等功能的分割槽上做此設定，可以保護系統安全。
 
友情提示：請您作完本文中的實驗後，別忘把檔案的許可權恢復原狀，以免帶來不必要的麻煩。
至此相信讀者已經對SetUID的作用有所瞭解，最後，還有一個大家要注意的問題，SetUID只針對具有可執行許可權的檔案有效，不具有x許可權的檔案被授予了SetUID會顯示標記為S（一下子由小s變成姐姐了），仔細想一下，如果沒有可執行許可權的話設定SetUID無任何意義。