RFC 2307、LDAP 与 uidNumber 的权限边界

摘要

RFC 2307 提议把 Unix 账户、用户组和网络资源写入 LDAP。它的 posixAccount 类包含 uidNumber，这是系统查找函数会读取的用户编号。
RFC 2307 的安全章节点明了写权限失控的后果：能够修改 uidNumber 的用户，可能把自己的账户改到与超级用户等同。

账户查找从一个整数开始

一个 Unix 进程不需要目录替它讲述用户是谁。它把整数交给 C 库，等待关联的账户记录。RFC 2307 用 getpwuid() 说明这类查找：函数把用户编号映射为登录名。按提案中的 LDAP 结构，查询会寻找 uidNumber 与程序所给整数相符的 posixAccount。

字段看起来像档案里的数字，系统却把它当成身份。

在 LDAP 进入这段历史之前，Unix 网络已经可以通过 Network Information Service（NIS）共享账户和主机信息。Sun 的管理手册把 NIS map 描述为两列式的键值表。一个域有主服务器保存 map，从服务器保留副本，客户端可以向任一服务器查询。passwd.byname 用登录名查账户，passwd.byuid 则以用户编号为键。管理员在主服务器上根据本地输入文件生成 map，再把结果推送到从服务器。

于是，本地文件的修改会变成网络上的答案。管理员更改源文件、重新生成 map，域内客户端就能读到新的记录。查找代码不会判断这个编号是否合理；它只使用收到的值。

SunOS 1999 年的手册还记下一段商标插曲：NIS 早先叫 Sun Yellow Pages，改名后功能没有变化。名称换了，账户 map 的实际作用并未变轻。

LDAP 更换了目录，权限仍由人决定

1997 年的 LDAPv3 规范，为访问基于 X.500 的目录提供了一种资源开销更低的方式。三个月后，RFC 2307 发布，标题是 An Approach for Using LDAP as a Network Information Service，它提议把 Unix 和 TCP/IP 数据表示成 LDAP 的类与属性。

范围远超主机名：账户、用户组、服务与协议编号、RPC 标识、启动参数、网络地址以及 NIS netgroup 都在其中。posixAccount 可以保存登录名、显示名、uidNumber、gidNumber、家目录和登录 shell。RFC 2307 还展示了如何把类似密码文件的一行转换成目录属性。

这种接入方式有它的工程逻辑。Unix 程序本来就通过 C 库查询账户；系统可以把查询源从本地文件切换到网络目录。RFC 2307 的实现部分记录了一台使用 LDAP 代替本地文件的 NIS 服务器、一套 C 库参考实现，以及把 /etc/passwd、/etc/hosts 等文件转为目录记录的脚本。

RFC 2307 没有命令所有 Unix 站点迁移。它以 Experimental 类别发布，提供的是组织名称服务的一种做法。文中说这套机制已经有过一些成功实现，却没有统计部署数量或普及范围。

编号划定了权限边界

RFC 2307 的安全章节直接谈到目录字段的系统权限。它要求只有管理员能够修改与操作系统实体有关的记录，并解释了原因：若用户可以更改自己的 uidNumber，就可能破坏安全性，让自己的账户与超级用户账户等同。

这是一项有条件的风险，控制点是写权限。Unix 软件把编号关联到账户；目录可以把关联发布给许多客户端；谁能修改记录，谁就能改变客户端看到的身份。Schema 规定字段长什么样，访问控制决定谁能改它。

同一章节还指出另一个查找与权限的冲突：若非特权用户能读到使用 crypt() 等常见方法生成的加密口令哈希，就可能遭遇字典和暴力破解。RFC 2307 把这种做法称为兼容既有 Unix 系统；在安全要求较高的环境中，它建议使用强认证服务。共享目录让查询更容易，也可能让敏感账户材料被更多客户端接触。

这些文件证明了设计提案和其中写明的风险，不能证明 LDAP 映射在 Unix 系统中的普及程度。RFC 2307 提到已有实现，但本证据包没有提供采用规模的统计。

真正的变化不是数据库多了一个 schema，而是操作系统同意让网络响应回答本机问题。uidNumber 可以只是一列，解释它的进程才让它产生效力。从 /etc/passwd 转到 NIS 或 LDAP，也把控制点移向网络：管理员必须知道哪个来源拥有权威、哪些副本包含最新 map、谁可以修改身份编号。