使用AFS, Active Directory和SSSD搭建用于集成电路设计的分布式存储系统 【四】AFS的工作原理 2

用户账户和AFS ID

Linux/Unix 的本地账户都有用户名称，同时还有一个叫 UID 的整数标识。前者是用户的登录名，后者是用户在操作系统里真正的代号。

与此类似，AFS 也有用户名和 AFS ID。前者是用户登录时使用的名字，比如 ximeng 或者 xuanwu, 后者是用户在文件系统里的真正代号和唯一标识。

因为 AFS 使用 Kerberos 进行身份验证，AFS 用户名必须和 Kerberos 服务的用户名一致。

当一个 AFS Cell 选择使用微软的 Active Directory 提供 Kerberos 验证时，AFS 的用户名就必须和 Active Directory 里的用户名一致。在 Active Directory 里，这个字段是每个个人用户的 userPrincipalName (UPN), 或者 sAMAccountName. 几乎所有的 Windows 域管理员都对这两个字段都不陌生。

新建的 Cell 的 AFS ID 默认从1开始，随着添加新用户逐渐增长。对于大多数情况而言，从 1 开始为AFS用户编号不是一个好选择。其中的原因对于实际部署十分重要。我们在这里解释一下。

我们从 Linux/Unix UID 说起。UID 之所以重要，和我们使用最频繁的一个命令，“ls” 相关。
当我们使用 ”ls -l” 命令来列举一个目录下的文件时，每一个文件的所有者(owner) 以及所有组 (group) 会一并列出。比如:

$ ls -l
drwxr-xr-x. 2 xmsguan users   6 May 27  2019 Desktop
drwxr-xr-x. 3 xmsguan users  29 Jun 15  2019 Downloads
drwxr-xr-x. 2 xmsguan users   6 May 27  2019 Public

其中 xmsguan 是所有者的名字，users 是所有组 (group) 的名字。这两个信息有助于我们了解文件的访问权限和创建者。

Linux/Unix 在执行上述命令时分作两步：第一步，从文件系统获取每个文件的 UID 和 GID，第二步，利用存储于 /etc/passwd 和 /etc/group 里的 UID, GID 与用户名的对应关系，将 UID 和 GID 替换成用户名与组名显示出来。

当 Unix/Linux 无法通过已知的查询方式从 UID 找到用户名时，（比如该用户已删除，但其文件和目录还存在磁盘上），Unix/Linux 将直接显示 UID。GID 的情况类似。

绝大多数用户都希望看到更有直观意义的用户名与组名，而非 UID 和 GID 这样的整数。

在 /afs 下执行同样的命令时，用户当然也希望看到正确的所有者名，而不是显示成 AFS ID，更不希望看到一个错误的所有者名。

但是 Cache Manager (AFS客户端)返回给操作系统的结果是 AFS ID. 这个 AFS ID 来自于 File Server 的记录。

如果我们能够保证客户端 Linux 里的用户 UID 与 AFS ID 完全一一对应，那么 Linux/Unix 根据 AFS ID 就能正确地显示出文件所有者的名字。

比如，如果 ximeng 这个用户的 AFS ID 是2001，他在 Linux 客户端里的 UID 也是 2001，那么 ximeng 拥有的 AFS 文件在 ”ls -l” 命令执行后就能正确显示其所有者是 ximeng.

相反，如果另一个 Linux 客户端里 UID 2001 对应的是另一个用户 xuanwu, 那么 ”ls -l” 返回的结果就会错误地将 ximeng 的文件的所有者解析成 xuanwu. 因为客户端在把返回的 AFS ID (2001) 当成 UID 来进行查询时，得到的结果是 xuanwu。

这显然会造成使用者的困惑，引起混乱。

为了避免这样的情况，部署 AFS 时需要特别注意保持网络文件系统的 ID 和客户端的 UID 一致。这当然也意味着所有接入共享文件系统的 Linux 客户端，根据 UID 查询的结果都要一致。

值得注意的是，实现 UID 的统一不仅是 AFS 一个文件系统的要求，而且是所有 Linux/Unix 共享文件系统部署时的需求。

在 Linux/Unix 世界里，有一些特殊的 UID 和 GID 几乎形成了约定俗成的规律。随操作系统一起安装时，一些特殊的 UID 已经被占用。比如 root 的 UID 总是 0， nobody 的 ID 是 99，mail 的 ID 是 8 等等。

如果一个 AFS 用户的 AFS ID 恰好是 99，那么在很多 Linux 客户端里，这个用户的 AFS 文件的所有者就可能被错误地显示成 nobody.

为了避免类似情况的出现，部署 AFS 时一般推荐将 AFS ID 的起始值定成大于 1000 的数值，比如从 2001 开始创建第一个 AFS 用户，以避免和 Linux 客户端已经存在的用户的 UID 冲突。

至于如何保持成百上千的客户端的 UID 与 AFS ID 一一对应，我们将在本系列的其他文章里做更详细地讨论。在这里需要记住的是 AFS 用户是由 AFS ID 来标识的这样一个概念。

访问控制的工作原理

AFS 的访问控制是建立在每一个目录上的。处于同一个目录里的文件具有相同的访问权限。AFS 提供了比 Linux 更强大灵活的访问控制机制。

Linux 或者 Unix 的用户都熟悉文件和目录的 mode bit 访问控制机制。为便于比较，我们略作解释。

当用户使用 ”ls -l” 命令查询文件列表时，一般能看到类似这样的结果:

$ ls -l
drwxr-xr-x. 2 xmsguan users   6 May 27  2019 Desktop

这里 drwxr-xr-x 就是目录 Desktop 的 mode bit. 第一个字母是 d，表明这是一个目录而不是一个文件。

接下来三个字符 rwx 代表目录所有者的权限，在这里这个目录的所有者 xmsguan 对该目录具有读、写和“执行”的权限。

跟在所有者权限后面的三个字符 r-x 代表组的权限。在这个例子里，所有 users 的成员对 Desktop 目录都具有读和“执行”的权限，而没有写权限。

最后三个字符 r-x 代表其他所有用户的权限。在这里这个目录允许其他所有用户读取和“执行”，但不允许他们更改该目录。

文件有执行权限比较好理解。一个目录为什么也有“执行”的权限？

原来 Linux 规定，一个目录可执行(有 x 权限)是指用户有权进入该目录。x 和r 合并在一起，给了用户浏览目录的权限。（如果你惊讶于这个事实，请不用自责，很多人都不知道这个“潜规则”。）

AFS 的权限定义比 Linux 更加全面和灵活。和使用上面这种三段式的 mode bit 不同，AFS 使用一种叫 ACL 的列表来定义目录的访问权限。ACL 是英文 Access Control List 的缩写，即字面意义的访问控制列表。今后为了醒目和称呼方便，我们将用ACL来指代目录的访问权限列表。

AFS 的 ACL 如何比 Linux 的方式更加灵活和全面呢？ACL 允许用户设定多个不同的组各自对目录的不同访问权限。

还以上面的例子来说明。例子里 Linux 的 Desktop 目录只对 users 这个组定义了只读权限。凡是不属于这个组的用户，如果不是目录的所有者，就只能统统归到“其他”这个类别里，以第三段字符代表的权限来限制其行为。

假设另外还有一个组叫 designers，我们同时希望给予 users 这个组只读权限，并且给予 designers 这个组的成员改写目录的权限，另外禁止其他所有用户进入该目录。这在 Linux 下面如何实现呢？显然事情就变得麻烦很多。即使能实现，上述 mode bit 的显示方式也难以完整描述我们的权限设定。

AFS 的 ACL 机制则允许我们做到这一点。我们只需要添加三条并列的记录到 ACL 里即可，第一条记录给予 users 组只读权限，第二条记录给予 designers 组写权限，第三条记录取消其他所有用户浏览目录的权限。

这种方式对于集成电路设计组织来说显然是十分有用的。比如，如果企业拿到了 TSMC 的 40nm 的设计套件 (PDK)，但不希望所有人都能访问，就可以使用 ACL 来控制不同项目组的访问权限。也许 CAD 组不仅可以读也可以写，这样可以根据需要重新订制 Virtuoso 的显示叠层设置或者更改默认的后道金属工艺选项。也许模拟设计组就只能读而不能写，而 contractors 组可能连进入该目录的权限都不具备。

我们将在未来的文章里详细说明 ACL 的具体规则和使用方法。这里我们希望读者首先知道 ACL 的存在，并且了解 ACL 允许对不同的组给予不同的访问权限，以及知道 ACL 是跟随目录一起储存在 File Server 里的。

既然 ACL 代表了某种访问权限，那么这个权限是如何被遵照执行的呢？

设想一个用户要访问 /afs 下的一个目录 abc/，她的客户端 Cache Manager 通过前文所述的方式查询了 Volume Location Database， 了解到当前存储该目录的 File Server 的地址，然后 Cache Manager 就会联系这个特定的 File Server，向其发送访问目录 abc/ 的请求。

接到请求的 File Server 在自己的记录里一查，发现 abc/ 确实存在，并且拿到了该目录的 ACL. 这个 ACL 里记录着几个不同的组以及他们各自的访问权限。现在的问题是，File Server 如何知道用户是否属于其中的任何一个组呢？

显然需要有一个 File Server 可以信赖的数据库来存储用户和组的信息，以便查询每一个组有哪些成员，以及每个成员属于哪些组。

AFS使用一个数据库服务来存储用户和组的数据。这个服务叫做 Protection Database Server. 和前面介绍的 Volume Location Database Server 类似，这个数据库服务也是一个 Cell 的必要组成部分，可以由多台服务器同时提供，也可以和 File Server 共存于一台服务器上。

一个 AFS Cell 的所有用户和 AFS ID，以及所有的 AFS 组都存储在 Protection Database Server 里。

当 File Server 收到某个用户的访问请求以后，就会联系 Protection Database Server，获得该用户所属的所有组的列表，并根据这个列表和 ACL 的比较结果，决定用户对一个目录的访问权限。

由此可见，Protection Database Server 是 AFS 里授权机制的主要环节，也是 AFS 安全性的基石之一。

在几乎所有的部署案例里，每一个用作数据库服务的机器都会同时运行Volume Location Database Server、Protection Database Server，以及另外几种 Database Server.

总结一下，AFS 的访问控制权限以建立在各级目录上的 ACL 来实现。每一级 ACL 只管自己这一级目录的 ACL，而不管其下子目录的 ACL。一个 AFS Cell 会运行一个或多个 Protection Database Server，File Server 通过查询 Protection Database Server来确定用户的组别，并结合 ACL 来确定请求者对目录的访问权限。