“用戶組”在 Linux 上到底是怎么工作的
就在上周，我還自認(rèn)為對 Linux 上的用戶和組的工作機制了如指掌。我認(rèn)為它們的關(guān)系是這樣的：
每個進程都屬于一個用戶（比如用戶?julia）
當(dāng)這個進程試圖讀取一個被某個組所擁有的文件時， Linux 會 a. 先檢查用戶julia?是否有權(quán)限訪問文件。（LCTT 譯注：此處應(yīng)該是指檢查文件的所有者是否就是?julia） b. 檢查?julia?屬于哪些組，并進一步檢查在這些組里是否有某個組擁有這個文件或者有權(quán)限訪問這個文件。
如果上述 a、b 任一為真（或者“其它”位設(shè)為有權(quán)限訪問），那么這個進程就有權(quán)限訪問這個文件。
比如說，如果一個進程被用戶?julia?擁有并且?julia?在awesome?組，那么這個進程就能訪問下面這個文件。
1 | r--r--r-- 1 root awesome???? 6872 Sep 24 11:09 file.txt |
然而上述的機制我并沒有考慮得非常清楚，如果你硬要我闡述清楚，我會說進程可能會在運行時去檢查?/etc/group?文件里是否有某些組擁有當(dāng)前的用戶。
然而這并不是 Linux 里“組”的工作機制
我在上個星期的工作中發(fā)現(xiàn)了一件有趣的事，事實證明我前面的理解錯了，我對組的工作機制的描述并不準(zhǔn)確。特別是 Linux?并不會在進程每次試圖訪問一個文件時就去檢查這個進程的用戶屬于哪些組。
我在讀了《Linux 編程接口》這本書的第九章（“進程資格”）后才恍然大悟（這本書真是太棒了），這才是組真正的工作方式！我意識到之前我并沒有真正理解用戶和組是怎么工作的，我信心滿滿的嘗試了下面的內(nèi)容并且驗證到底發(fā)生了什么，事實證明現(xiàn)在我的理解才是對的。
用戶和組權(quán)限檢查是怎么完成的
現(xiàn)在這些關(guān)鍵的知識在我看來非常簡單! 這本書的第九章上來就告訴我如下事實：用戶和組 ID 是進程的屬性，它們是：
真實用戶 ID 和組 ID；
有效用戶 ID 和組 ID；
保存的 set-user-ID 和保存的 set-group-ID；
文件系統(tǒng)用戶 ID 和組 ID（特定于 Linux);
補充的組 ID；
這說明 Linux?實際上檢查一個進程能否訪問一個文件所做的組檢查是這樣的：
檢查一個進程的組 ID 和補充組 ID（這些 ID 就在進程的屬性里，并不是實時在?/etc/group?里查找這些 ID）
檢查要訪問的文件的訪問屬性里的組設(shè)置
確定進程對文件是否有權(quán)限訪問（LCTT 譯注：即文件的組是否是以上的組之一）
通常當(dāng)訪問控制的時候使用的是有效用戶/組 ID，而不是真實用戶/組 ID。技術(shù)上來說當(dāng)訪問一個文件時使用的是文件系統(tǒng)的 ID，它們通常和有效用戶/組 ID 一樣。（LCTT 譯注：這句話針對 Linux 而言。）
將一個用戶加入一個組并不會將一個已存在的進程（的用戶）加入那個組
下面是一個有趣的例子：如果我創(chuàng)建了一個新的組：panda?組并且將我自己（bork）加入到這個組，然后運行?groups?來檢查我是否在這個組里：結(jié)果是我（bork）竟然不在這個組？！
1 2 3 4 5 6 7 8 9 10 | 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?并不在上面的組里！為了再次確定我們的發(fā)現(xiàn)，讓我們建一個文件，這個文件被?panda?組擁有，看看我能否訪問它。
1 2 3 4 5 | $??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?并不會改變這一點。
那進程一開始是怎么得到用戶的組的呢？
這真是個非常令人困惑的問題，對嗎？如果進程會將組的信息預(yù)置到進程的屬性里面，進程在初始化的時候怎么取到組的呢？很明顯你無法給你自己指定更多的組（否則就會和 Linux 訪問控制的初衷相違背了……）
有一點還是很清楚的：一個新的進程是怎么從我的命令行解釋器（/bash/fish）里被執(zhí)行而得到它的組的。（新的）進程將擁有我的用戶 ID（bork），并且進程屬性里還有很多組 ID。從我的命令解釋器里執(zhí)行的所有進程是從這個命令解釋器里?fork()?而來的，所以這個新進程得到了和命令解釋器同樣的組。
因此一定存在一個“第一個”進程來把你的組設(shè)置到進程屬性里，而所有由此進程而衍生的進程將都設(shè)置這些組。而那個“第一個”進程就是你的登錄程序login shell，在我的筆記本電腦上，它是由?login?程序（/bin/login）實例化而來。登錄程序以 root 身份運行，然后調(diào)用了一個 C 的庫函數(shù) ——?initgroups?來設(shè)置你的進程的組（具體來說是通過讀取?/etc/group?文件），因為登錄程序是以 root 運行的，所以它能設(shè)置你的進程的組。
讓我們再登錄一次
好了！假如說我們正處于一個登錄程序中，而我又想刷新我的進程的組設(shè)置，從我們前面所學(xué)到的進程是怎么初始化組 ID 的，我應(yīng)該可以通過再次運行登錄程序來刷新我的進程組并啟動一個新的登錄命令！
讓我們試試下邊的方法：
1 2 3 4 | $ 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! |
當(dāng)然，成功了！現(xiàn)在由登錄程序衍生的程序的用戶是組?panda?的一部分了！太棒了！這并不會影響我其他的已經(jīng)在運行的登錄程序（及其子進程），如果我真的希望“所有的”進程都能對?panda?組有訪問權(quán)限。我必須完全的重啟我的登錄會話，這意味著我必須退出我的窗口管理器然后再重新登錄。（LCTT 譯注：即更新進程樹的樹根進程，這里是窗口管理器進程。）
newgrp 命令
在 Twitter 上有人告訴我如果只是想啟動一個刷新了組信息的命令解釋器的話，你可以使用?newgrp（LCTT 譯注：不啟動新的命令解釋器），如下：
1 2 3 | 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 將設(shè)置有效用戶 ID
其實我一直對一個進程如何以?setuid root?的權(quán)限來運行意味著什么有點似是而非。現(xiàn)在我知道了，事實上所發(fā)生的是：setuid?設(shè)置了
“有效用戶 ID”! 如果我（julia）運行了一個?setuid root?的進程（ 比如?passwd），那么進程的真實用戶 ID 將為?julia，而有效用戶 ID 將被設(shè)置為?root。
passwd?需要以 root 權(quán)限來運行，但是它能看到進程的真實用戶 ID 是?julia?，是?julia?啟動了這個進程，passwd?會阻止這個進程修改除了?julia?之外的用戶密碼。
下載文檔
