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