嗨！就在上周，我还自认为对 Linux 上的用户和组的工作机制了如指掌。我认为它们的关系是这样的：
每个进程都属于一个用户（比如用户 julia）
当这个进程试图读取一个被某个组所拥有的文件时， Linux 会 a. 先检查用户julia 是否有权限访问文件。（LCTT 译注：此处应该是指检查文件的所有者是否就是 julia） b. 检查 julia 属于哪些组，并进一步检查在这些组里是否有某个组拥有这个文件或者有权限访问这个文件。
如果上述 a、b 任一为真（或者“其它”位设为有权限访问），那么这个进程就有权限访问这个文件。
比如说，如果一个进程被用户 julia 拥有并且 julia 在awesome 组，那么这个进程就能访问下面这个文件。
r--r--r--1 root awesome 6872Sep2411:09file.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
$ sudochown root:panda panda-file.txt
$ sudochmod660 panda-file.txt
$ cat panda-file.txt
cat: panda-file.txt:Permission denied