使用者ID：UID与GID
在使用Linux的过程中，经常会遇到各种用户ID（user identifier, UID）和组ID（group identifier, GID），Linux也是通过对这些ID的管理实现的自主访问控制（discretionary access control, DAC）。
用户ID（英语：user identifier，一般缩写为User ID或UID），全称用户标识符，在类UNIX系统中是内核用来辨识用户的一个无符号整型数值，亦是UNIX文件系统与进程的必要组成部分之一。[1]
虽然我们登录Linux主机时使用的是账户，但是对于Linux系统而言，它只认识ID。而ID与账户的对应就记录在/etc/passwd文件中。可以通过命令id查看各个id与账户名的对应关系：
从上图中我们可以看到，我的用户名是wang，它的UID是1000，GID也是1000。
UID范围
在不同系统中，UID值范围也有所不同，但一般来说UID是由一个16bit的无符号整数表示的，其范围在0-65535之间。
| UID | 账户 |
|---|---|
| 0 | root，超级用户的UID总为0 |
| 65535 | nobody，总是UID的最大值 |
| 1~999 | 一般约定是系统保留范围，由系统使用 |
| 1000~65534 | 一般用户UID |
UID与GID分类
值得注意的是，以下的分类都是针对进程而言的，只有进程才会有下述几种ID。
| 中文 | 英文 | 解释 |
|---|---|---|
| 有效用户ID与有效组ID | Effective UID, EUID, Effective GID, GID | 在创建和访问文件时发挥作用。具体来说，创建文件时，系统内核将根据创建文件的进程的EUID与EGID设定文件的所有者/组属性，而在访问文件时，内核亦根据访问进程的EUID与EGID决定其能否访问文件。 |
| 真实用户ID与真实用户组 | Real UID, RUID, Real GID, RGID | 用于辨识进程的真正所有者，且会影响到进程发送信号的权限。 |
| 暂存用户ID | Saved UID, SUID | 特权权限运行的进程暂时需要做一些不需特权的操作时使用，这种情况下进程会暂时将自己的有效用户ID从特权用户（常为root）对应的UID变为某个非特权用户对应的UID，而后将原有的特权用户UID复制为SUID暂存；之后当进程完成不需特权的操作后，进程使用SUID的值重置EUID以重新获得特权。 |
| 文件系统用户ID | File System UID, FSUID | 在Linux中使用，且只用于对文件系统的访问权限控制，在没有明确设定的情况下与EUID相同（若FSUID为root的UID，则SUID、RUID与EUID必至少有一亦为root的UID），且EUID改变也会影响到FSUID。设立FSUID是为了允许程序（如NFS服务器）在不需获取向给定UID账户发送信号的情况下以给定UID的权限来限定自己的文件系统权限。 |
访问文件
举例而言，假设我要执行以下命令，sudo vim /etc/apt/sources.list，我当前的用户是wang，那么这个这个进程的RUID就是1000（对应wang这个账户），而sudo指使使用root权限，因此该进程的EUID就是0（root账户）。我们查看/etc/apt/sources.list文件的所有者和所有组，它的所有者是root，组是root。因此我们必须使用sudo进行提权，也即是修改进程的EUID为0，这样才能够访问/etc/apt/sources.list文件，但是RUID依然是1000。
创建文件
再举例创建文件。如下图所示：
文件的所有组和所有者依然与进程的EUID和EGID指定，而非RUID和RGID。
父子进程
子进程继承了父进程所有的各种UID和GID。
权限控制
这里描述的权限控制是指Linux中基于用户和用户组以及r\w\x权限的控制，其中r表示可读，w表示可写，x表示可执行。
Linux一般把文件存取的身份分为三个类别：owner/group/others，且三种身份都各有read/write/execute权限。
查看/etc/shadow的详细信息如下图所示：
分析如下：
| 权限 | 链接数 | 所有者 | 所有组 | 文件大小 | 文件最后被修改的时间 | 文件名 |
|---|---|---|---|---|---|---|
| -rw-r----- | 1 | root | shadow | 1.6K | May 9 2021 | /etc/shadow |
对权限进行详细分析如下，每个文件的权限都有10个字符表示，其中-表示无对应权限，这十个字符可分为四组，第一组就是第一个字符；表示文件类型，第二组就是第2、3、4个字符，是所有者拥有的权限，依次是r/w/x；第5、6、7个字符表示组权限，依次是r/w/x；第8、9、10个字符表示其他人的权限，依次是r/w/x。如果所在位置为-，则表示无对应权限。
对应上述/etc/shadow文件的权限为，所有者即root拥有读写权限，组shadow只有读权限，其他人没有任何权限。
rwx与421
在Linux系统中，可以使用chmod命令来改变文件的权限，例如：sudo chmod 640 /etc/shadow。这个含义就是将文件/etc/shadow的所有者权限改为6即rw；组权限改为4即r；其他人权限改为0即无任何权限。之所以6表示rw，4表示r，这是因为Linux是通过位来表示权限的。
因为文件拥有三种不同的权限r/w/x，Linux就使用3bit作为权限记录，如果是只读的那么就是100，如果是只写的就是010，如果是只可执行的就是001，可读可写的呢就是110啦。读者自行将二进制转换为十进制，就会发现6就表示110，也就是可读可写不可执行的意思啦。
当然，这里描述的3bit权限位并不是实际上Linux的权限实现机制，而是为了读者方便理解记忆，数字与权限的对应关系。实际的权限记录比较复杂。
关于权限的一些问题
-
一个文件可有只写权限但是不可读吗？
答案是可以的，如下图所示。
-
一个文件不具有可执行权限就一定不可执行吗？有了可执行权限就一定可以执行吗？
答案是不一定。
-
目录的rwx
- 目录的只读访问不允许使用cd进入目录，必须要有执行的权限才能进入。
- 只有执行权限只能进入目录，不能看到目录下的内容，要想看到目录下的文件名和目录名，需要可读权限。
- 一个文件能不能被删除，主要看该文件所在的目录对用户是否具有写权限，如果目录对用户没有写权限，则该目录下的所有文件都不能被删除，文件所有者除外
- 目录的w位不设置，即使你拥有目录中某文件的w权限也不能写该文件
进程UID与文件权限类型的匹配
根据前文我们已经知道，对文件的访问和创建等操作需要检查的都是EUID，而不是RUID。即使RUID是普通用户，而EUID是root则就拥有了对root所能访问的所有文件的权限。对应/etc/shadow我们就检查对应的root权限是读写，因此该进程就可以对/etc/shadow进行读写操作。如果，该进程的EUID不是root，但是是属于shadow组的，那么就只有读权限，否则没有任何权限。
Set-UID提权[2]
在一个典型的计算机系统中，用户需要使用超级用户的权限来完成诸如修改密码的操作。一种方式是通过守护进程（Windows下成为服务）方式来实现，另一种方式是通过设置Set-UID权限的方式来实现。
Set-UID程序和其他unix程序唯一的区别就在于他有一个特殊的标志位：Set-UID比特位。使用这个比特位的目的是告诉操作系统，当运行这个程序时应当与未设置该位的程序相区分。
我们在前文中提过，权限匹配是通过EUID来实现的。对于非Set-UID程序而言，进程的EUID是和RUID一致的，当它被一个用户ID为5000的用户运行时，RUID和EUID都是5000。而当执行一个Set-UID程序时，RUID和EUID的值是不一样的，RUID的值取决于执行该程序的用户ID，而EUID则取决于Set-UID程序文件的所有者。
设置Set-UID
提权测试
ACL（Access Control List）规则
前文所述的规则又称为UGO（user，group，others）规则，这套机制比较简单。在自主访问控制中，还有ACL规则，作为补充。在Linux系统中，ACL用于设定用户针对文件的权限。
ACL主要有两种命令进行控制，getfacl和setfacl。
# 例子源于https://blog.csdn.net/pwl999/article/details/110878563
[root@localhost ~]# useradd zhangsan
[root@localhost ~]# useradd lisi
[root@localhost ~]# useradd st
[root@localhost ~]# groupadd tgroup
// 添加需要试验的用户和用户组，省略设定密码的过程
[root@localhost ~]# mkdir /project #建立需要分配权限的目录
[root@localhost ~]# chown root:tgroup /project/
// 改变/project目录的属主和属组
[root@localhost ~]# chmod 770 /project/
// 指定/project目录的权限
[root@localhost ~]# ll -d /project/
drwxrwx--- 2 root tgroup 4096 1月19 04:21 /project/
// 查看一下权限，已经符合要求了
// 这时st学员来试听了，如何给她分配权限
[root@localhost ~]# setfacl -m u:st:rx /project/
// 给用户st赋予r-x权限，使用"u:用户名：权限" 格式
[root@localhost /]# cd /
[root@localhost /]# ll -d project/
drwxrwx---+ 3 root tgroup 4096 1月19 05:20 project/
// 使用ls-l査询时会发现，在权限位后面多了一个"+"，表示此目录拥有ACL权限
[root@localhost /]# getfacl project
// 查看/prpject目录的ACL权限
#file: project <-文件名
#owner: root <-文件的属主
#group: tgroup <-文件的属组
user::rwx <-用户名栏是空的，说明是属主的权限
user:st:r-x <-用户st的权限
group::rwx <-组名栏是空的，说明是属组的权限
mask::rwx <-mask权限
other::--- <-其他人的权限
// 大家可以看到，st 用户既不是 /prpject 目录的属主、属组，也不是其他人，我们单独给 st 用户分配了 r-x 权限。这样分配权限太方便了，完全不用先辛苦地规划用户身份了。
推荐阅读
-
鸟哥的Linux私房菜--第四版 第13章
-
Linux DAC权限管理详解
参考文献
用户ID--维基百科 ↩︎
杜文亮. 计算机安全导论：深度实践[M]. 高等教育出版社, 2020. ↩︎