本文主要介紹 Linux 系統中，權限控制的基本原理。
安全模型
在 Linux 系統中，我們所有的操作實質都是在進行進程訪問文件的操作。我們訪問文件需要先取得相應的訪問權限，而訪問權限是通過 Linux 系統中的安全模型獲得的。
對於 Linux 系統中的安全模型，我們需要知道下面兩點：
- Linux 系統上最初的安全模型叫 DAC, 全稱是 Discretionary Access Control ，翻譯為自主訪問控制。
- 後來又增加設計了一個新的安全模型叫 MAC, 全稱是 Mandatory Access Control, 翻譯為強制訪問控制。
注意, MAC 和 DAC 不是互斥的， DAC 是最基本的安全模型，也是通常我們最常用到的訪問控制機制是 Linux 必須具有的功能， 而 MAC 是構建在 DAC 之上的加強安全機制，屬於可選模塊。訪問前， Linux 系統通常都是先做 DAC 檢查， 如果沒有通過則操作直接失敗 ; 如果通過 DAC 檢查並且系統支持 MAC 模塊，再做 MAC 權限檢查。
為區分兩者，我們將支持 MAC 的 Linux 系統稱作 SELinux, 表示它是針對 Linux 的安全加強系統。
這裡，我們將講述 Linux 系統中的 DAC 安全模型。
DAC 安全模型
DAC 的核心內容是：在 Linux 中，進程理論上所擁有的權限與執行它的用戶的權限相同。其中涉及的一切內容，都是圍繞這個核心進行的。
用戶和組 ID 信息控制
用戶、組、口令信息
通過 /etc/passwd 和 /etc/group 保存用戶和組信息，通過 /etc/shadow 保存密碼口令及其變動信息， 每行一條記錄。
用戶和組分別用 UID 和 GID 表示，一個用戶可以同時屬於多個組，默認每個用戶必屬於一個與之 UID 同值同名的 GID 。
對於 /etc/passwd , 每條記錄字段分別為 用戶名: 口令（在 /etc/shadow 加密保存）：UID:GID（默認 UID）: 描述註釋: 主目錄: 登錄 shell(第一個運行的程序)
對於 /etc/group ， 每條記錄字段分別為 組名：口令（一般不存在組口令）：GID：組成員用戶列表（逗號分割的用戶 UID 列表）
對於 /etc/shadow ，每條記錄字段分別為： 登錄名: 加密口令: 最後一次修改時間: 最小時間間隔: 最大時間間隔: 警告時間: 不活動時間:
舉例
以下是對用戶和組信息的舉例。 /etc/shadow 中的口令信息為加密存儲，不舉例。
文件權限控制信息
文件類型
Linux 中的文件有如下類型：
- 普通文件， 又包括文本文件和二進制文件， 可用 touch 創建；
- 套接字文件， 用於網絡通訊，一般由應用程序在執行中間接創建；
- 管道文件是有名管道，而非無名管道， 可用 mkfifo 創建；
- 字符文件和塊文件均為設備文件， 可用 mknod 創建；
- 鏈接文件是軟鏈接文件，而非硬鏈接文件, 可用 ln 創建。
訪問權限控制組
分為三組進行控制：
- user 包含對文件屬主設定的權限
- group 包含對文件屬組設定的權限
- others 包含對其他者設定的權限
可設定的權限
下面給出常見（但非全部）的權限值， 包括：
- r 表示具有讀權限。
- w 表示具有寫權限。
- x 一般針對可執行文件 / 目錄，表示具有執行 / 搜索權限。
- s 一般針對可執行文件 / 目錄，表示具有賦予文件屬主權限的權限，只有 user 和 group 組可以設置該權限。
- t 一般針對目錄，設置粘滯位後，有權限的用戶只能寫、刪除自己的文件, 否則可寫、刪除目錄所有文件。舊系統還表示可執行文件運行後將 text 拷貝到交換區提升速度。
舉例
通過 ls -l 可以查看到其文件類型及權限，通過 chmod 修改權限。
舉例來說，
輸出中， 第 1 個字符表示文件類型，其中，普通文件 (-)、目錄文件 (d)、套接字文件 (s)，管道文件 (p)，字符文件 (c)，塊文件 (b)，鏈接文件 (l)； 第 2 個字符開始的 -rwxr-xr-x 部分表示文件的權限位，共有 9 位。
對於文件 /usr/bin/qemu-i386 , 這個權限控制的含義是：
- 第 2~4 位的 rwx 表示該文件可被它的 owner （屬主）以 r 或 w 或 x 的權限訪問。
- 第 5~7 位的 r-x 表示該文件可被與該文件同一屬組的用戶以 r 或 x 的權限訪問
- 第 8~10 位的 r-x 表示該文件可被其它未知用戶以 r 或 x 的權限訪問。
對於 test/, test2/, test3/ 設定的權限：
- r,w,x 權限對每一權限控制組的權限用一位 8 進制來表示； 例如： 755 表示 rwxr-xr-x 。
- s,t 權限會替代 x 位置顯示；設定 s,t 權限則需在對應的、用於控制 r,w,x 的 8 進制權限控制組前追加數字； s 權限用於屬主屬組控制， t 用於其它控制。
- 設定屬主 s 需追加 4, 設定屬組 s 追加 2, 設定其它者 t 權限追加 1 ； 例如前面對 test/ 設定 t, 則用 1775, 表示 rwxrwxr-t 。
進程權限控制信息
進程權限
對於進程，有如下屬性與文件訪問權限相關：
- effective user id : 進程訪問文件權限相關的 UID （簡寫為 euid ）。
- effective group id : 進程訪問文件權限相關的 GID （簡寫為 egid ）。
- real user id : 創建該進程的用戶登錄系統時的 UID （簡寫為 ruid ）。
- real group id : 創建該進程的用戶登錄系統時的 GID （簡寫為 rgid ）。
- saved set user id : 拷貝自 euid 。
- saved set group id : 拷貝自 egid 。
舉例
我們可以使用 ps 和 top 選擇查看具有 euid 和 ruid 的進程。或者通過 top 來查看進程的 euid 和 ruid
通過 top 來查看的例子：
首先輸入 top 得到類似如下
這裡通過 -d 選項延長 top 的刷新頻率便於操作。此處可見，只有 USER 字段，表示相應進程的 effective user id.
打開 read user id 的顯示選項：
a. 在 top 命令運行期間，輸入 f, 可以看見類似如下行：
b. 輸入 c 即可打開 Real user name 的顯示開關。
c. 最後 Return 回車回到 top 中，即可看到 real user id 的選項。此時輸入`o`，可調整列次序。最終我們可看到包含`effective user id`和`real user id`的輸出如下：
進程訪問文件的權限控制策略
規則
進程訪問文件大致權限控制策略
對於進程訪問文件而言，最重要的是 euid, 所以其權限屬性均以 euid 為 “中心”。
- 進程的 euid 一般默認即為 其 ruid 值
- 若可執行文件的可執行權限位為 s ，進程對其調用 exec 後，其 euid 被設置為該可執行文件的 user id
- 進程的 saved set user id 拷貝自 euid.
- 當進程的 euid 與文件的 user id 匹配時，進程才具有文件 user 權限位所設定的權限
- 組權限 egid 的控制規則類似。
通過 exec 執行文件修改權限屬性
通過 exec 調用可執行文件之時：
- 進程 ruid 值始終不變；
- saved set-user ID 始終來自 euid ；
- euid 值取決於文件的 set-user-ID 位是否被設置。
如下：
通過 setuid(uid) 系統調用修改權限屬性
通過 setuid(uid) 修改權限屬性之時：
- superuser 可順利修改 ruid, euid, saved set-user ID ；
- unprivileged user 只能在 uid 與 ruid 相等時修改 euid, 其它無法修改。
舉例
再舉幾個比較特別的例子：
設置了 set-user-id
如前所述，這個輸出的含義是，對於 /usr/bin/sudo 文件，
- 第 1~3 位的 rws 表示該文件可被它的 owner（屬主）以 r 或 w 或 s 的權限訪問
- 第 4~6 位的 r-x 表示該文件可被與該文件同一屬組的用戶以 r 或 x 的權限訪問。
- 第 7~9 位的 r-x 表示該文件可被其它未知用戶以 r 或 x 的權限訪問。
這樣設置之後，對於 owner，具有讀、寫、執行權限，這一點沒有什麼不同。但是對於不屬於 root 組的普通用戶進程來說，卻大不相同。
普通用戶進程執行 sudo 命令時通過其 others 中的 x 獲得執行權限，再通過 user 中的 s 使得普通用戶進程臨時具有了 sudo 可執行文件屬主 ( root ) 的權限，即超級權限。
這也是為什麼通過 sudo 命令就可以讓普通用戶執行許多管理員權限的命令的原因。
設置了 stick-bit
這樣設置之後，對於 /tmp 目錄，任何人都具有讀、寫、執行權限，這一點沒有什麼不同。但是對於 others 部分設置了粘滯位 t, 其功能卻大不相同。
若目錄沒設置粘滯位，任何對目錄有寫權限者都則可刪除其中任何文件和子目錄，即使他不是相應文件的所有者，也沒有讀或寫許可 ; 設置粘滯位後，用戶就只能寫或刪除屬於他的文件和子目錄。
這也是為什麼任何人都能向 /tmp 目錄寫文件、目錄，卻只能寫和刪除自己擁有的文件或目錄的原因。
舉一個 man 程序的應用片斷，描述 set-user-id 和 saved set-user-id 的使用
man 程序可以用來顯示在線幫助手冊， man 程序可以被安裝指定 set-user-ID 或者 set-group-ID 為一個指定的用戶或者組。
man 程序可以讀取或者覆蓋某些位置的文件，這一般由一個配置文件 (通常是 /etc/man.config 或者 /etc/manpath.config ) 或者命令行選項來進行配置。
man 程序可能會執行一些其它的命令來處理包含顯示的 man 手冊頁的文件。
為防止處理出錯， man 會從兩個特權之間進行切換：運行 man 命令的用戶特權，以及 man 程序的擁有者的特權。
需要抓住的主線：當只執行 man 之時，進程特權就是 man 用戶的特權， 當通過 man 執行子進程（如通過 !bash 引出 shell 命令）時，用戶切換為當前用戶，執行完又切換回去。
過程如下：
- 假設 man 程序文件被用戶 man 所擁有，並且已經被設置了它的 set-user-ID 位，當我們 exec 它的時候，我們有如下情況：
- – real user ID = 我們的用戶 UID
- – effective user ID = man 用戶 UID
- – saved set-user-ID = man 用戶 UID
- man 程序會訪問需要的配置文件和 man 手冊頁。這些文件由 man 用戶所擁有，但是由於 effective user ID 是 man, 文件的訪問就被允許了。
- 在 man 為我們運行任何命令的時候，它會調用 setuid(getuid())) (getuid() 返回的是 real user id).
- 因為我們不是 superuser 進程，這個變化只能改變 effective user ID. 我們會有如下情況：
- 現在 man 進程運行的時候把我們得 UID 作為它的 effective user ID. 這也就是說，我們只能訪問我們擁有自己權限的文件。也就是說，它能夠代表我們安全地執行任何 filter.
- – real user ID = 我們的用戶 UID(不會被改變)
- – effective user ID = 我們的用戶 UID
- – saved set-user-ID = man 的用戶 UID(不會被改變)
- 當 filter 做完了的時候， man 會調用 setuid(euid).
- 這裡， euid 是 man 用戶的 UID.(這個 ID 是通過 man 調用 geteuid 來保存的) 這個調用是可以的，因為 setuid 的參數和 saved set-user-ID 是相等的。(這也就是為什麼我們需要 saved set-user-ID). 這時候我們會有如下情況：
- – real user ID = 我們的用戶 UID(不會被改變)
- – effective user ID = man 的 UID
- – saved set-user-ID = man 的用戶 UID(不會被改變)
- 由於 effective user ID 是 man, 現在 man 程序可以操作它自己的文件了。
- 通過這樣使用 saved set-user-ID, 我們可以在進程開始和結束的時候通過程序文件的 set-user-ID 來使用額外的權限。然而，期間我們卻是以我們自己的權限運行的。如果我們無法在最後切換回 saved set-user-ID, 我們就可能會在我們運行的時候保留額外的權限。
下面我們來看看如果 man 啟動一個 shell 的時候會發生什麼：
- 這裡的 shell 是 man 使用 fork 和 exec 來啟動的。
- 因為這時 real user ID 和 effective user ID 都是我們的普通用戶 UID(參見 step3)， 所以 shell 沒有其它額外的權限.
- 啟動的 shell 無法訪問 man 的 saved set-user-ID(man) , 因為 shell 的 saved set-user-ID 是由 exec 從 effective user ID 拷貝過來的。
- 在執行 exec 的子進程 ( shell ) 中，所有的 user ID 都是我們的普通用戶 ID.
實際上，我們描述 man 使用 setuid 函數的方法不是特別正確，因為程序可能會 set-user-ID 為 root . 這時候， setuid 會把所有三種 uid 都變成你設置的 id，但是我們只需要設置 effective user ID。
閱讀更多 IT小白進階之路 的文章
