linux 中實際使用者ID”、“有效使用者ID”和“儲存的設定使用者ID”三個術語

 THE USER ID OF A PROCESS 

核心會給每個進程關聯兩個和進程ID無關的使用者ID，一個是真實使用者ID，還有一個是有效使用者ID或者稱為 setuid（set user ID）。真實使用者ID用於標識由誰為正在啟動並執行進程負責。有效使用者ID用於為新建立的檔案分配所有權、檢查檔案訪問許可，還用於通過kill系統調用向其它進程發送訊號時的許可檢查。核心允許一個進程以調用exec一個setuid程式或者顯式執行setuid系統調用的方式改變它的有效使用者ID。 

所謂setuid程式是指一個設定了許可模式欄位中的setuid bit的可執行檔。當一個進程exec一個setuid程式的時候，核心會把進程表以及u區中的有效使用者ID設定成該檔案所有者的ID。為了區分這兩個欄位，我們把進程表中的那個欄位稱作儲存使用者ID。可以通過一個例子來示範這兩個欄位的區別。 

setuid系統調用的文法是 setuid(uid) ，其中，uid是新的使用者ID，該系統調用的結果取決於有效使用者ID的當前值。如果調用進程的有效使用者ID是超級使用者，核心會把進程表以及u區中的真實和有效使用者ID都設定成uid。如果調用進程的有效使用者ID不是超級使用者，僅當uid等於真實使用者ID或儲存使用者ID時，核心才會把u區中的有效使用者ID設定成uid。否則，該系統調用將返回錯誤。一般來說，一個進程會在fork系統調用期間從父進程那兒繼承它的真實和有效使用者ID，這些數值即使經過exec系統調用也會保持不變。 

儲存在u區中的有效使用者ID是最近一次setuid系統調用或是exec一個setuid程式的結果；只有它會被用於檔案訪問許可。進程表中的儲存使用者ID使得一個進程可以通過執行setuid系統調用把有效使用者ID設定成它的值，以此來恢複最初的有效使用者ID。 

setuid程式的例子：login，mkdir。

引用：Uresh Vahalia 的《UNIX Internals：The New Frontiers》一書中對這個問題的論述。。。  

p27 

2.3.3 User Credentials 

UID和GID這樣的標識符會影響檔案的所有權和訪問許可，以及向其它進程發送訊號的能力。這些屬性統稱為憑證。 

每個進程都有兩對ID ——真實的和有效。當一個使用者登入的時候，login程式會把兩對ID設定成密碼資料庫（/etc/passwd檔案，或某些如Sun Microsystems的NIS之類的分布式機制）中指定的UID和GID。當一個進程fork的時候，子進程將從父進程那兒繼承它的憑證。 

有效UID和有效GID印象檔案的建立和訪問。在建立檔案的時候，核心將檔案的所有者屬性設定成建立進程的有效UID和有效GID。在訪問檔案的時候，核心使用進程的有效UID和GID來判斷它是否能夠訪問該檔案。真實UID和真實GID標識進程的真實所有者，會影響到發送訊號的許可權。對於一個沒有超級使用者權限的進程來說，僅當它的真實或有效UID於另一個進程的真實UID匹配時它才能向那個進程發送訊號。 

有三個系統調用可以改變憑證。如果一個進程調用exec執行一個安裝為suid模式的程式，核心將把進程的有效UID修改成檔案的所有者。同樣，如果該程式安裝為sgid模式，核心則會去修改調用進程的有效GID。UNIX提供這個特性是想賦予使用者特殊的許可權以完成一些特定的任務。 

一個使用者還可以通過調用setuid或setgid來改變它的憑證。超級使用者可以通過這些系統調用改變真實的和有效UID以及GID。普通使用者則只能通過這些調用來把它們的有效UID或GID改回到真實的數值。 

System V和BSD UNIX在處理憑證方面存在著一些差別。SVR3還維護了一個saved UID和saved GID，分別是在調用 exec之前的有效UID和GID的數值。setuid和setgid系統調用還可以把有效ID恢複為儲存的數值。4.3BSD不支援這一特性，它允許一個使用者屬於一個輔組（supplemental group）的集合（使用setgroups系統調用）。使用者建立的檔案將屬於它的主組（primary group），而使用者則既可以訪問屬於主組的檔案，也可以訪問屬於輔組的檔案。 

SVR4整合了上述所有特性。它支援附組，也會在exec的時候維護saved UID和GID。 

setuid程式的例子：passwd。

引用：Marshall Kirk McKusick, George V. Neville-Neil 的《The Design and Implementation of the FreeBSD Operating System》一書中對這個問題的論述。。。  

3.7 User, Group, and Other Identifiers 

每個FreeBSD進程的狀態裡都有一個UID和一組GID。一個進程的檔案系統存取權限就是由它的UID和GIDs來定義的。通常，這些標識符都是新進程建立的時候從父進程那兒自動繼承過來的。只有超級使用者才能修改一個進程的真實UID或真實GID。這個方案在各種特權之間進行了嚴格的區分，確保除了超級使用者之外的其它任何使用者都無法獲得特權。 

每個檔案都有三組許可bit，分別用於所有者、組以及其它使用者的讀、寫或執行許可。這些許可bit將按如下順序進行檢查： 
    1、如果檔案的UID和進程的UID相同，則僅應用所有者的許可，不再檢查組和其它使用者的許可。 
    2、如果UID不匹配，但檔案的GID和進程的眾多GID之一匹配，則僅引用組的許可，不再檢查所有者和其它使用者的許可。 
    3、僅當進程UID和GID與檔案的UID和GID都不匹配時，才會去檢查其它使用者的許可。如果這些許可不允許所請求的操作，該操作就會失敗。 

一個進程的UID和GIDs是從它的父進程那兒繼承來的。當一個使用者登入的時候，login程式會在執行exec系統調用運行使用者的登入shell之前設定好UID和GIDs，因此，後續的所有進程都會繼承到恰當的標識符。 

我們經常會想賦予一個使用者有限的額外特權。......為瞭解決這個問題，核心允許程式在運行過程中建立被賦予特權的程式。以不同的UID啟動並執行程式被稱為setuid程式，以一個額外的組提高權限執行的程式被稱為setgid程式。當運行一個setuid程式的時候，進程的許可將被擴充以包括與程式相關聯的UID的許可。該程式的UID就被稱為進程的有效UID，而進程最初的UID則被稱為真實UID。同樣，執行一個setgid程式會把進程的許可擴充為程式的GID的許可，相應的也有有效GID和真實GID的定義。 

系統可以通過setuid和setgid程式來提供對檔案或服務的受控訪問。當然，這樣的程式必須仔細編寫，以保證它們只具有一些有限的功能。 

UID和GIDs是作為每個進程的狀態的一部分來維護的。由於曆史原因，GIDs被實現成了一個顯著的GID（即有效GID）和一個GIDs的輔助數組，不過在邏輯上則被看作是一組GIDs。在FreeBSD中，那個顯著的GID就是GIDs數組中的第一個條目。輔助數組的大小是固定的（FreeBSD中是16），不過可以通過重新編譯核心來修改這個數值。 

FreeBSD是通過把運行setgid程式的進程的輔組數組中的第0個元素設定成檔案的屬組來實現setgid功能的。之後就可以像普通進程那樣對許可進行檢查了。由於存在額外的組，setgid程式就能夠比一個運行沒有特殊許可權的程式的使用者進程訪問更多的檔案。為了避免在運行一個setgid 程式的時候丟失與第0個數組元素中的組相關聯的特權，login程式會在初始化使用者的輔組數組的時候將第0個數組元素複製到第一個數組元素中。因此，當啟動並執行setgid程式修改第0個元素的時候，使用者不會丟失任何特權，因為曾經儲存在第0個數組元素中的組仍然可以從第一個數組元素中得到。 

setuid功能是通過把進程的有效UID從使用者的數值修改為被啟動並執行程式的數值來實現的。和setgid一樣，保護機制此時將毫不變樣地允許訪問，同時也不會意識到程式正在運行setuid。由於一個進程在同一時刻只能有一個UID，在運行setuid的時候就可能會丟失某些特權。在載入新的有效UID的時候，之前的真實UID將會繼續作為真實UID。不過真實UID是不會用於任何確認檢查的。 

一個setuid進程在運行過程中可能會想臨時取消它的特殊許可權。比如，它可能只在運行開始和結束的時候需要訪問某個受限檔案的特殊許可權。在其餘的已耗用時間中，它應當只具有真實使用者的許可權。在BSD的早期版本中，特權的回收是通過對真實的和有效UID進行切換來完成的。由於只有有效UID被用於存取控制，這個方法既提供了所需的語義，又提供了一個隱藏特殊許可權的地方。這個方法的缺點是很容易就混淆了真實的和有效UID。 

在FreeBSD中，使用了一個額外的標識符，即saved UID來記錄setuid程式的身份。當一個程式被exec之後，它的有效UID會被拷貝到saved UID中。下表中的第1行表示了一個沒有特權的程式，它的真實、有效以及saved UID都是真實使用者的數值。第2行正在運行中的 setuid程式，它的有效UID被設定成了具有相應特權的UID，而這個特權UID也會被拷貝到saved UID中。 

Actions affecting the real, effective, and saved UIDs. 
_________________________________________________________________ 
Action            Real    Effective    Saved 

1.exec-normal     R       R            R 
2.exec-setuid     R       S            S 
3.seteuid(R)      R       R            S 
4.seteuid(S)      R       S            S 
5.seteuid(R)      R       R            S 
6.exec-normal     R       R            R 

Key:R-real user identifier; S-special-privilege user identifier 
_________________________________________________________________ 

seteuid系統調用只會修改有效UID，而不會影響真實的或saved UID。seteuid系統調用被允許將有效UID修改為真實的或 saved UID的數值。表中的第3行和第4行表示了一個setuid程式在一直保持正確的真實UID的同時是如何放棄和重新取回它的特殊許可權的。第5 行和第6行表示了一個setuid程式可以運行一個子進程而不賦予它特殊許可權。首先，它會把它的有效UID設定成真實UID。然後，當exec那個子進程的時候，有效UID就會被拷貝到saved UID中，從此就會失去對特權UID的所有訪問。 

與此類似，也有一個saved GID機制，允許進程在真實GID和最初的有效GID之間進行切換。