由于下面的原因,在早期解决这个问题要简单得多,以避免technical debt的积累.即使你发现自己已经处于这种情况,在不久的将来处理它可能比让它继续建设更好.

网络文件系统

这个问题似乎集中在使用本地文件系统的机器之间传输文件的狭窄范围,这允许机器特定的所有权状态.

网络文件系统注意事项很容易成为尝试保持UID / GID映射同步的最大情况,因为您通常可以在进入图片时抛出窗口中提到的“已实现”.当然,您现在可能没有在这些主机之间共享网络文件系统……但未来呢？你能诚实地说,在你当前的主机或将来创建的主机之间引入网络文件系统永远不会有用例吗？假设不是这样,这不是一个前瞻性的想法.

假设/ home是以下示例中host1和host2之间共享的网络文件系统.

>不同意权限：/ home / user1由每个系统上的其他用户拥有.这可以防止用户跨系统一致地访问或修改其主目录.
> chown wars：用户提交一个请求在特定系统上修复其主目录权限的票证是很常见的.在host2上修复此问题会破坏host1上的权限.在有人退后一步并意识到正在进行一场拉锯战之前,它有时可以使用其中几张票.唯一的解决方案是修复不同意的ID映射.这导致…
> UID / GID重新平衡地狱：以后纠正ID的复杂性会随着在多台计算机上纠正单个用户所涉及的重映射数量呈指数级增长. (user1的ID为user2,但user2的ID为user17 ……而这只是集群中的第一个系统)等待解决问题的时间越长,这些链变得越复杂,通常需要停机时间多个服务器上的应用程序,以便正确地同步.
>安全问题：host2上的user2与host1上的user1具有相同的UID,允许它们在不知道user1的情况下写入host2上的/ home / user1.然后使用user1的权限在host1上评估这些更改.什么可能出错？ (如果user1是app用户,dev中的某个人会发现它是可写的并且会进行更改.这是事实证明的事实.)

还有其他场景,这些只是最常见的场景.

名字并不总是一种选择

根据数字ID编写的任何脚本或配置文件在您的环境中都会变得不可移植.一般不是问题,因为大多数人不会硬编码这些,除非他们绝对需要……但有时你使用的工具并没有给你一个选择.在这些情况下,您不得不维护n个不同版本的脚本或配置文件.

示例：pam_succeed_if允许您使用user,uid和gid的字段……显然不存在“组”选项.如果您被置于多个系统预期实施某种形式的基于组的访问限制的位置,那么您将拥有不同的PAM配置变体. (或者至少要有一个GID,你必须避免碰撞)

集中管理

natxo的答案很好地涵盖了这一点.