https://jvns.ca/blog/2017/11/20/groups/
作者 | Julia Evans
譯者 | DavidChenLiang ??共計翻譯:7.0 篇 貢獻時間:56 天
嗨!就在上週,我還自認為對 Linux 上的使用者和組的工作機制瞭如指掌。我認為它們的關係是這樣的:
julia
)julia
是否有許可權訪問檔案。(LCTT 譯註:此處應該是指檢查檔案的所有者是否就是 julia
) b. 檢查 julia
屬於哪些組,併進一步檢查在這些組裡是否有某個組擁有這個檔案或者有許可權訪問這個檔案。比如說,如果一個行程被使用者 julia
擁有並且 julia
在awesome
組,那麼這個行程就能訪問下麵這個檔案。
r--r--r-- 1 root awesome 6872 Sep 24 11:09 file.txt
然而上述的機制我並沒有考慮得非常清楚,如果你硬要我闡述清楚,我會說行程可能會在執行時去檢查 /etc/group
檔案裡是否有某些組擁有當前的使用者。
然而這並不是 Linux 裡“組”的工作機制
我在上個星期的工作中發現了一件有趣的事,事實證明我前面的理解錯了,我對組的工作機制的描述並不準確。特別是 Linux 並不會在行程每次試圖訪問一個檔案時就去檢查這個行程的使用者屬於哪些組。
我在讀了《Linux 程式設計介面[1]》這本書的第九章(“行程資格”)後才恍然大悟(這本書真是太棒了),這才是組真正的工作方式!我意識到之前我並沒有真正理解使用者和組是怎麼工作的,我信心滿滿的嘗試了下麵的內容並且驗證到底發生了什麼,事實證明現在我的理解才是對的。
使用者和組許可權檢查是怎麼完成的
現在這些關鍵的知識在我看來非常簡單! 這本書的第九章上來就告訴我如下事實:使用者和組 ID 是行程的屬性,它們是:
這說明 Linux 實際上檢查一個行程能否訪問一個檔案所做的組檢查是這樣的:
/etc/group
裡查詢這些 ID)通常當訪問控制的時候使用的是有效使用者/組 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
程式(/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 程式設計介面[1]》這本書裡有很多 Linux 上一些功能的罕見使用方法以及 Linux 上所有的事物到底是怎麼執行的詳細解釋,這裡我就不一一展開了。那本書棒極了,我上面所說的都在該書的第九章,這章在 1300 頁的書裡只佔了 17 頁。
我最愛這本書的一點是我只用讀 17 頁關於使用者和組是怎麼工作的內容,而這區區 17 頁就能做到內容完備、詳實有用。我不用讀完所有的 1300 頁書就能得到有用的東西,太棒了!
via: https://jvns.ca/blog/2017/11/20/groups/
作者:Julia Evans[3] 譯者:DavidChen 校對:wxy
本文由 LCTT 原創編譯,Linux中國 榮譽推出