我很好奇是否存在标准的预期行为，以及在具有相同 UID 的 Linux/Unix 上创建多个帐户时是否被认为是不好的做法。我已经用这个在 RHEL5 上做了一些测试，它的表现和我预期的一样，但我不知道我是否用这个技巧来诱惑命运。
例如，假设我有两个具有相同 ID 的帐户：
a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash
这意味着：
- 我可以使用自己的密码登录每个帐户。
- 我创建的文件将具有相同的 UID。
- 诸如“ls -l”之类的工具会将 UID 列为文件中的第一个条目（在本例中为 a1）。
- 我避免了两个帐户之间的任何权限或所有权问题，因为它们实际上是同一个用户。
- 我对每个帐户都进行了登录审核，因此我可以更好地跟踪系统上发生的事情。
所以我的问题是：
- 这种能力是设计出来的，还是只是它的工作方式？
- 这会在 *nix 变体中保持一致吗？
- 这是公认的做法吗？
- 这种做法是否会产生意想不到的后果？
请注意，这里的想法是将其用于系统帐户而不是普通用户帐户。
我的意见：
这种能力是设计出来的，还是只是它的工作方式？
它是设计好的。自从我开始使用 *NIX 以来，您已经能够将用户放在公共组中。使 UID 相同而没有问题的能力只是一个预期的结果，就像所有事情一样，如果管理不正确，可能会带来问题。
这会在 *nix 变体中保持一致吗？
我相信是这样。
这是公认的做法吗？
被接受为通常以一种或另一种方式使用，是的。
这种做法是否会产生意想不到的后果？
除了登录审核之外，您没有其他任何东西。除非你真的想要那样，否则就开始吧。
它适用于所有 Unix 吗？是的。
这是一种很好的技术吗？不，还有其他更好的技术。例如，正确使用 unix 组和严格控制的“sudo”配置可以实现相同的目标。
我已经看到了一个使用它没有问题的地方。在 FreeBSD 中，传统的做法是创建一个名为“toor”（root 向后拼写）的第二个 root 帐户，其中 /bin/sh 作为默认 shell。这样，如果 root 的 shell 搞砸了，您仍然可以登录。
我无法为您的问题提供规范的答案，但有趣的是，我的公司多年来一直在使用 root 用户执行此操作，并且从未遇到任何问题。我们创建了一个“kroot”用户（UID 0），其存在的唯一原因是使用 /bin/ksh 作为 shell，而不是 /bin/sh 或 bin/bash。我知道我们的 Oracle DBA 对他们的用户做了类似的事情，每次安装有 3 或 4 个用户名，所有用户 ID 都相同（我相信这样做是为了让每个用户都有单独的主目录。我们至少已经这样做了十年，在 Solaris 和 Linux 上。我认为它按设计工作。
我不会使用普通用户帐户执行此操作。正如您所指出的，在初始登录后，一切都会回到日志文件中的第一个名称，所以我认为一个用户的操作可能会被伪装成日志中另一个用户的操作。对于系统帐户，虽然效果很好。
这种做法是否会产生意想不到的后果？
我知道一个问题。Cron 不能很好地使用此 UID 别名。尝试从 Python 脚本运行“crontab -i”来更新 cron 条目。然后在shell中运行“crontab -e”进行修改。
请注意，现在 cron（我认为是 vixie）将为 a1 和 a2 更新相同的条目（在 /var/spool/cron/a1 和 /var/spool/cron/a2 中）。
这种能力是设计出来的，还是只是它的工作方式？
是这样设计的。
这会在 *nix 变体中保持一致吗？
它应该，是的。
这是公认的做法吗？
取决于你的意思。这种类型的东西回答了一个非常具体的问题（参见 root/toor 帐户）。在其他任何地方，您都在要求将来出现一个愚蠢的问题。如果您不确定这是否是正确的解决方案，则可能不是。
这种做法是否会产生意想不到的后果？
通常习惯将用户名和 UID 视为可互换的。正如其他一些人指出的那样，登录/活动审核将是不准确的。您还需要查看任何与用户相关的脚本/程序（您的发行版的 useradd、usermod、userdel 脚本、任何定期维护脚本等）的行为。
您想通过将这两个用户添加到新组并授予该组您需要的权限来完成此操作而无法完成的任务？
这是我见过的所有发行版的预期行为，也是“敌人”用来隐藏具有 root 访问权限的帐户的常用技巧。
它当然不是标准的（我在任何地方都没有看到过这个），但是如果你认为合适的话，不应该有任何理由不能在你自己的环境中使用它。
现在想到的唯一问题是这可能会使审计变得困难。如果您有两个具有相同 uid/gid 的用户，我相信您在分析日志时将很难弄清楚哪个用户做了什么。
共享主要组 ID 很常见，因此问题实际上围绕UID展开。
我以前这样做是为了给某人root访问权限，而不必泄露root密码-效果很好。（虽然我认为 sudo 会是一个更好的选择）
我要小心的主要事情是删除其中一个用户 - 程序可能会混淆并删除两个用户，或者属于两者的文件，或类似的东西。
事实上，我认为程序员可能会假设用户和 UID 之间存在 1:1 的关系，因此与我为 userdel 描述的类似的其他程序很可能会产生意想不到的后果。
顺便说一句——这个问题/答案已针对今天的操作系统进行了更新。
引自redhat：管理唯一 UID 和 GID 编号分配，它描述了 UID 和 GID 的使用及其管理以及生成器（ID 服务器）的方式
同样，允许访问系统的实用程序的行为可能无法预测（相同的参考）：
当“第一”的概念定义不明确时，问题就来了。根据安装的服务，用户名可能保存在可变大小的散列中，该散列将根据不一致的因素返回不同的用户名。（我知道这是真的，因为我有时会尝试使用 2 个带有一个 ID 的用户名，一个是本地用户名，另一个是我想映射到 UID 的 domain.username（我最终在完全不同的方式），但我可以使用“usera”登录，执行“who”或“id”并随机查看“userb”或“usera”。
有一个用于从一个组中检索多个 UID 值的接口（具有单个 GID 的组被设计为与多个 UID 相关联），但是没有可移植的接口来返回一个 UID 的名称列表，因此任何人都期望相同或系统之间的类似行为，甚至同一系统上的应用程序可能会感到意外。
在 Sun（现在的 oracle）的 yp(yellowpages) 或 NIS(NetworkInformationServices) 中，也有很多关于唯一性要求的引用。设置特殊功能和服务器以跨多个服务器和域分配唯一ID（例如uid_allocd、gid_allocd - UID 和 GID 分配器守护程序手册页
可以检查的第三个来源是 Microsoft 的 NFS 帐户映射服务器文档。NFS 是一个 unix 文件共享协议，它们描述了 ID 如何维护文件权限和访问权限。在那里，他们写道：
用户标识符。这是 UNIX 操作系统用来标识用户的无符号整数，并且在 passwd 文件中必须是唯一的。
GID。这是 UNIX 内核用来标识组的无符号整数，并且在组文件中必须是唯一的。MS-NFS-管理页面
虽然某些操作系统可能允许多个名称/UID（也许是 BSD 衍生产品？），但大多数操作系统都依赖于它是唯一的，并且当它们不是时可能会出现不可预测的行为。
注意-我正在添加此页面，因为有人将此过时的条目称为对现代实用程序的支持，以适应非唯一的 UID/GID ......大多数情况下都没有。
我也不知道这是否是一个好主意，但我在一些地方使用了上述行为。大多数情况下，它用于访问 ftp/sftp 服务器和更新网站内容的帐户。它似乎没有破坏任何东西，并且似乎比使用多个帐户更容易处理权限。
刚刚遇到了一个（相当模糊的）问题，源于使用具有相同 UID 的多个帐户，并认为我会分享它作为为什么这不是好的做法的一个例子。
在我的例子中，供应商在 RHEL 7 上设置了一个 Informix 数据库服务器和一个 Web 应用程序服务器。在设置过程中，创建了多个 UID 为 0 的“root”帐户（不要问我为什么）。即，“root”、“user1”和“user2”，都具有 UID 0。
RHEL 7 服务器后来使用 winbind 加入了 Active Directory 域。此时，Informix DB 服务器无法再启动。运行
oninit失败，并显示一条错误消息，指出"Must be a DBSA to run this program".这是我们在故障排除时发现的：
在已加入 Active Directory 的系统上运行
id root或getent passwd 0（将 UID 0 解析为用户名）将随机返回“user1”或“user2”而不是“root”。Informix 显然依靠字符串比较来检查启动它的用户的文本用户名是否是“root”，否则会失败。
如果没有 winbind，
id root并且getent passwd 0会始终返回“root”作为用户名。修复是禁用缓存和持久性
/etc/nscd.conf：在此更改之后，UID 0 再次一致地解析为“root”并且 Informix 可以启动。
希望这对某人有用。