Linux系統的安全性得益於其進程權限和文件權限的控制機制。今天抽空梳理下Linux下的進程權限控制相關的文件權限涉及一點。首先明確四個名詞：真實用戶ID（real ID）、有效用戶ID(effective ID)、保存用戶ID（Saved ID）、文件系統用戶ID（File ID）。后面的特性同樣適用組。
- 真實用戶ID（real ID）
是指啟動進程的用戶ID，進程如果擁有root權限啟動以后就可以調用setuid（newid）系統調用修改。修改之后四個ID的值都會變為newid，程序剛開始運行第一行命令時四個值都是啟動這個進程的用戶ID。
- 有效用戶ID(effective ID)
指正在運行（強調他現在屬於誰）進程的用戶ID，看着讓人疑惑啊，這不就是真實用戶ID嗎？其實不是，因為程序在運行過程中可以修改當前正在運行自己的人（為真實用戶ID或着保存用戶ID），所以啟動進程的用戶是真實ID但是運行進程的是有效ID。最初他倆是相同的，進程運行期間的權限認證使用的就是有效用戶ID。
- 保存用戶ID（Saved ID）
保存進程的最初有效用戶ID，所以一般情況下一個程序如果運行期間不修改自己的ID則，前面這個三個ID應該是相同的
- 文件系統用戶ID（File ID）
文件系統ID。他在Linux下的作用主要是體現在進程創建文件后的新文件的權限處理時使用的用戶。Uunix上使用的是有效用戶ID。
程序在運行過程是可以修改自己的有效用戶ID從而修改自己的權限的，不過一般情況下應用程序是無法增加自己的權限的，所以修改進程有效用戶ID我理解這個機制是為了在合適的時候減小進程權限而存在的，比如以root作為真實ID，但是以普通用戶狀態運行，避免程序越線操作。Linux下修改程序用戶ID的系統調用主要有四個兩類。
- 修改進程ID int seuid（uid_t uid）
這個系統調用的執行效果取決與當前調用進程的有效用戶ID，如果是root則它將修改所有上面的四個ID（其實是五個還有一個suid），所以相當於他執行了這一個系統調用后就是放棄了自己的root權限，相反此時如果進程的有效用戶ID是一個普通的用戶，則他將只會修改有效用戶ID和文件系統用戶ID行為退化的和下面的系統調用用法相同。
- 修改進程有效用戶ID int seteuid(uid_t uid)
正如前面所說的一樣，這個系統調用只會修改進程的有效用戶ID和文件系統用戶ID，但是這個函數的操作可以講有效ID設置成的新ID值只能是真實用戶ID 和保存用戶ID其中之一。
總結就是：
非root用戶是無法出讓權限給其它用戶，只有root用戶才能出讓。非root用戶權限本來就只有他自己的權限，所以其他用戶他可能都是不可見的。setuid和seteuid是有區別的，setuid是永久的放棄root用戶權限，轉讓給非root用戶后，無法再restore到root用戶，seteuid是臨時放棄root用戶權限，可以通過seteuid(0),restore到root權限。
最后還有就是suid，這是設置用戶ID，他是存在與文件權限位rwx中的，如果一個可執行文件通過chmod設置了s位則，任何用戶對這個文件有執行權限的用戶執行了這個可執行文件，則其有效用戶ID就是這個文件設置的s位的用戶ID，常見用戶是給文件屬主用戶設置這一位通過chmod u+s filename 命令。例如一個可執行文件的屬主是user1 並且設置了屬主設置權限位s，則user2去執行這個可執行文件時這個進程的 真實用戶ID 有效用戶ID 保存用戶ID分別是 user2 user1 user1 。此外一個進程權限的繼承，當使用 fork 子進程的時候，子進程全部繼承父進程四個 uid，和父進程 uid 相同當使用exec系列函數時候，會把suid（文件S標志位）置為euid。這就是Linux下的進程權限控制的相關內容，還有一個疑惑就是既然有效用戶ID常常和文件系統ID一起被修改，那么為什么需要他呢，還是我理解的有問題，如果有明白其中原由的大牛告知一下。
參考：https://www.jb51.net/article/98188.htm