一個文件都有一個所有者, 表示該文件是誰創建的. 同時, 該文件還有一個組編號, 表示該文件所屬的組, 一般為文件所有者所屬的組.
　　如果是一個可執行文件, 那么在執行時, 一般該文件只擁有調用該文件的用戶具有的權限. 而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

轉載于:https://www.cnblogs.com/Nyan-Workflow-FC/p/4820854.html

總結

以上是生活随笔為你收集整理的Liunx UID and GID的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。