![跨 Linux 机器同步 UID/GID 有什么好处?](https://linux22.com/image/634623/%E8%B7%A8%20Linux%20%E6%9C%BA%E5%99%A8%E5%90%8C%E6%AD%A5%20UID%2FGID%20%E6%9C%89%E4%BB%80%E4%B9%88%E5%A5%BD%E5%A4%84%EF%BC%9F.png)
在我深入研究如何在不同的 Linux 机器之间同步 UID/GID 之前,我想知道这样做实际上有什么好处?
我知道这可以使文件同步相对容易(因为所有权“自然”保留)。但是,这也可以通过其他方式实现,具体取决于传输服务。
还有什么能从一致的 UID/GID 中受益吗?
答案1
技术债务
由于以下原因,简单得多尽早解决这个问题,以避免积累技术债务。即使您发现自己已经处于这种情况,最好在不久的将来解决它,而不是让它继续积累。
网络文件系统
这个问题似乎集中在具有本地文件系统的机器之间传输文件的狭窄范围内,这允许机器特定的所有权状态。
网络文件系统考虑因素很容易成为尝试保持 UID/GID 映射同步的最大案例,因为一旦它们进入画面,您通常就可以将您提到的“以其他方式实现”抛到九霄云外。当然,您可能没有在这些主机之间共享网络文件系统现在...但未来会怎样?你能诚实地说,你当前的主机或未来创建的主机之间永远不会引入网络文件系统的用例吗?否则,这种假设就不是很有远见。
假设在以下示例中,是在和/home
之间共享的网络文件系统。host1
host2
- 不同意权限:
/home/user1
在每个系统上由不同的用户拥有。这阻止用户跨系统一致地访问或修改其主目录。 - 战争:用户提交请求在特定系统上修复其主目录权限的票据是很常见的。修复 上的此问题
host2
会破坏 上的权限host1
。有时可能需要处理几张这样的票据,然后才会有人退后一步,意识到这是一场拉锯战。唯一的解决方案是修复不一致的 ID 映射。这导致... - UID/GID 重新平衡地狱:后期纠正 ID 的复杂性增加指数地通过涉及在多台机器上纠正单个用户的重新映射次数。 (
user1
ID为user2
,但user2
ID为user17
……这只是集群中的第一个系统)等待修复问题的时间越长,这些链就会变得越复杂,通常需要关闭多台服务器上的应用程序才能使一切正常同步。 - 安全问题:
user2
on具有与onhost2
相同的 UID ,允许他们在 不知情的情况下向on写入内容。然后使用 的权限对这些更改进行评估。可能出现什么问题?(如果是应用程序用户,开发人员中的某个人user1
host1
/home/user1
host2
user1
host1
user1
user1
将要发现它是可写的,并且将要做出改变。这是已被时间证明的事实。)
还有其他情况,这些只是最常见的情况的例子。
名字并不总是一个选择
任何针对数字 ID 编写的脚本或配置文件在您的环境中本质上都不可移植。通常这不是问题,因为大多数人不会对这些进行硬编码,除非绝对需要……但有时您使用的工具不会让您选择。在这些情况下,您被迫维护n不同版本的脚本或配置文件。
例如:pam_succeed_if
允许您使用user
、uid
和gid
... 字段,但“组”选项明显缺失。如果您处于需要多个系统实施某种形式的基于组的访问限制的位置,则您必须nPAM 配置的不同变体。(或者至少一个必须避免冲突的 GID)
集中管理
natxo 的回答很好地解释了这一点。
答案2
一旦达到一定规模(而且总是比您想象的要快),您就会意识到更改密码或禁用所有主机上某个人的帐户是一件非常麻烦的事情。这就是为什么人们使用带有 LDAP 数据库的系统(或 NIS,但不要这样做,现在不安全),例如 openldap 或现在出色的 freeipa。
您将所有帐户/组信息保存在中央数据库中,所有主机共享该信息。您可以从那里做更多的事情:当然,使用用户信息获取文件权限,但也为所有具有 ldap 绑定的应用程序创建虚拟用户,而不必在那里创建用户(许多 Web 应用程序可以使用 ldap 作为其用户数据库),维护中央 sudo 规则数据库,分发您的 autofs 环境,保留您的 dns 区域,...