[[245214]]

 嗨！就在上周，我還自認為對 Linux 上的用戶和組的工作機制了如指掌。我認為它們的關系是這樣的：

1. 每個進程都屬于一個用戶（比如用戶 julia）
2. 當這個進程試圖讀取一個被某個組所擁有的文件時， Linux 會 a. 先檢查用戶julia 是否有權限訪問文件。（LCTT 譯注：此處應該是指檢查文件的所有者是否就是 julia） b. 檢查 julia 屬于哪些組，并進一步檢查在這些組里是否有某個組擁有這個文件或者有權限訪問這個文件。
3. 如果上述 a、b 任一為真（或者“其它”位設為有權限訪問），那么這個進程就有權限訪問這個文件。

比如說，如果一個進程被用戶 julia 擁有并且 julia 在awesome 組，那么這個進程就能訪問下面這個文件。

r--r--r-- 1 root awesome     6872 Sep 24 11:09 file.txt

然而上述的機制我并沒有考慮得非常清楚，如果你硬要我闡述清楚，我會說進程可能會在運行時去檢查 /etc/group 文件里是否有某些組擁有當前的用戶。

然而這并不是 Linux 里“組”的工作機制

我在上個星期的工作中發現了一件有趣的事，事實證明我前面的理解錯了，我對組的工作機制的描述并不準確。特別是 Linux 并不會在進程每次試圖訪問一個文件時就去檢查這個進程的用戶屬于哪些組。

我在讀了《Linux 編程接口》這本書的第九章（“進程資格”）后才恍然大悟（這本書真是太棒了），這才是組真正的工作方式！我意識到之前我并沒有真正理解用戶和組是怎么工作的，我信心滿滿的嘗試了下面的內容并且驗證到底發生了什么，事實證明現在我的理解才是對的。 

用戶和組權限檢查是怎么完成的

現在這些關鍵的知識在我看來非常簡單! 這本書的第九章上來就告訴我如下事實：用戶和組 ID 是進程的屬性，它們是：

• 真實用戶 ID 和組 ID；
• 有效用戶 ID 和組 ID；
• 保存的 set-user-ID 和保存的 set-group-ID；
• 文件系統用戶 ID 和組 ID（特定于 Linux);
• 補充的組 ID；

這說明 Linux 實際上檢查一個進程能否訪問一個文件所做的組檢查是這樣的：

• 檢查一個進程的組 ID 和補充組 ID（這些 ID 就在進程的屬性里，并不是實時在 /etc/group 里查找這些 ID）
• 檢查要訪問的文件的訪問屬性里的組設置
• 確定進程對文件是否有權限訪問（LCTT 譯注：即文件的組是否是以上的組之一）

通常當訪問控制的時候使用的是有效用戶/組 ID，而不是真實用戶/組 ID。技術上來說當訪問一個文件時使用的是文件系統的 ID，它們通常和有效用戶/組 ID 一樣。（LCTT 譯注：這句話針對 Linux 而言。） 

將一個用戶加入一個組并不會將一個已存在的進程（的用戶）加入那個組

下面是一個有趣的例子：如果我創建了一個新的組：panda 組并且將我自己（bork）加入到這個組，然后運行 groups 來檢查我是否在這個組里：結果是我（bork）竟然不在這個組？！

bork@kiwi~> sudo addgroup panda
Adding group `panda' (GID 1001) ...
Done.
bork@kiwi~> sudo adduser bork panda
Adding user `bork' to group `panda' ...
Adding user bork to group panda
Done.
bork@kiwi~> groups
bork adm cdrom sudo dip plugdev lpadmin sambashare docker lxd

panda 并不在上面的組里！為了再次確定我們的發現，讓我們建一個文件，這個文件被 panda 組擁有，看看我能否訪問它。

$  touch panda-file.txt
$  sudo chown root:panda panda-file.txt
$  sudo chmod 660 panda-file.txt
$  cat panda-file.txt
cat: panda-file.txt: Permission denied

好吧，確定了，我（bork）無法訪問 panda-file.txt。這一點都不讓人吃驚，我的命令解釋器并沒有將 panda 組作為補充組 ID，運行 adduser bork panda 并不會改變這一點。 

那進程一開始是怎么得到用戶的組的呢？

這真是個非常令人困惑的問題，對嗎？如果進程會將組的信息預置到進程的屬性里面，進程在初始化的時候怎么取到組的呢？很明顯你無法給你自己指定更多的組（否則就會和 Linux 訪問控制的初衷相違背了……）

有一點還是很清楚的：一個新的進程是怎么從我的命令行解釋器（/bash/fish）里被執行而得到它的組的。（新的）進程將擁有我的用戶 ID（bork），并且進程屬性里還有很多組 ID。從我的命令解釋器里執行的所有進程是從這個命令解釋器里 fork() 而來的，所以這個新進程得到了和命令解釋器同樣的組。

因此一定存在一個“***個”進程來把你的組設置到進程屬性里，而所有由此進程而衍生的進程將都設置這些組。而那個“***個”進程就是你的登錄程序login shell，在我的筆記本電腦上，它是由 login 程序（/bin/login）實例化而來。登錄程序以 root 身份運行，然后調用了一個 C 的庫函數 —— initgroups 來設置你的進程的組（具體來說是通過讀取 /etc/group 文件），因為登錄程序是以 root 運行的，所以它能設置你的進程的組。 

讓我們再登錄一次

好了！假如說我們正處于一個登錄程序中，而我又想刷新我的進程的組設置，從我們前面所學到的進程是怎么初始化組 ID 的，我應該可以通過再次運行登錄程序來刷新我的進程組并啟動一個新的登錄命令！

讓我們試試下邊的方法：

$ sudo login bork
$ groups
bork adm cdrom sudo dip plugdev lpadmin sambashare docker lxd panda
$ cat panda-file.txt # it works! I can access the file owned by `panda` now!

當然，成功了！現在由登錄程序衍生的程序的用戶是組 panda 的一部分了！太棒了！這并不會影響我其他的已經在運行的登錄程序（及其子進程），如果我真的希望“所有的”進程都能對 panda 組有訪問權限。我必須完全的重啟我的登錄會話，這意味著我必須退出我的窗口管理器然后再重新登錄。（LCTT 譯注：即更新進程樹的樹根進程，這里是窗口管理器進程。） 

newgrp 命令

在 Twitter 上有人告訴我如果只是想啟動一個刷新了組信息的命令解釋器的話，你可以使用 newgrp（LCTT 譯注：不啟動新的命令解釋器），如下：

sudo addgroup panda
sudo adduser bork panda
newgrp panda # starts a new shell, and you don't have to be root to run it!

你也可以用 sg panda bash 來完成同樣的效果，這個命令能啟動一個bash 登錄程序，而這個程序就有 panda 組。 

seduid 將設置有效用戶 ID

其實我一直對一個進程如何以 setuid root 的權限來運行意味著什么有點似是而非。現在我知道了，事實上所發生的是：setuid 設置了
“有效用戶 ID”! 如果我（julia）運行了一個 setuid root 的進程（ 比如 passwd），那么進程的真實用戶 ID 將為 julia，而有效用戶 ID 將被設置為 root。

passwd 需要以 root 權限來運行，但是它能看到進程的真實用戶 ID 是 julia ，是 julia 啟動了這個進程，passwd 會阻止這個進程修改除了 julia 之外的用戶密碼。 

就是這些了！

在《Linux 編程接口》這本書里有很多 Linux 上一些功能的罕見使用方法以及 Linux 上所有的事物到底是怎么運行的詳細解釋，這里我就不一一展開了。那本書棒極了，我上面所說的都在該書的第九章，這章在 1300 頁的書里只占了 17 頁。

我***這本書的一點是我只用讀 17 頁關于用戶和組是怎么工作的內容，而這區區 17 頁就能做到內容完備、詳實有用。我不用讀完所有的 1300 頁書就能得到有用的東西，太棒了！