I am curious whether there is a standard expected behavior and whether it is considered bad practice when creating more than one account on Linux/Unix that have the same UID. I've done some testing on RHEL5 with this and it behaved as I expected, but I don't know if I'm tempting fate using this trick.

As an example, let's say I have two accounts with the same IDs:


What this means is:

  • I can log in to each account using its own password.
  • Files I create will have the same UID.
  • Tools such as "ls -l" will list the UID as the first entry in the file (a1 in this case).
  • I avoid any permissions or ownership problems between the two accounts because they are really the same user.
  • I get login auditing for each account, so I have better granularity into tracking what is happening on the system.

So my questions are:

  • Is this ability designed or is it just the way it happens to work?
  • Is this going to be consistent across *nix variants?
  • Is this accepted practice?
  • Are there unintended consequences to this practice?

Note, the idea here is to use this for system accounts and not normal user accounts.

10 Answers 10


My opinion:

Is this ability designed or is it just the way it happens to work?

It is designed. Since I started using *NIX, you have been able to place users on common groups. The ability to have the UID be the same without problems is just an intended result that, like everything, might bring problems if incorrectly managed.

Is this going to be consistent across *nix variants?

I believe so.

Is this accepted practice?

Accepted as in generally used in one way or another, yes.

Are there unintended consequences to this practice?

Other than login auditing, you have nothing else. Unless you wanted exactly that, to start with.

  • Note, this isn't placing users in the same group, it is giving them identical group IDs. So there would be a group a1 with GID 5000 and group a2 with GID 5000. The more critical concept here is the identical UIDs, though, as you could get the group handling as you propose.
    – Tim
    May 5, 2009 at 18:58
  • 1
    The name given to *NIX groups is irrelevant. It is the GID what matters. By giving the same GID to more than one group you are accomplishing little; why not to use the same group name/GID for as many users as you want? The UID is a slightly different matter, since the friendly name gets logged.
    – user1797
    May 5, 2009 at 19:03
  • I probably should have stuck with just discussing UID, as it is the more relevant item in the question.
    – Tim
    May 5, 2009 at 19:10
  • This answer is not valid today.
    – Astara
    Aug 28, 2014 at 0:13
  • @Astara: Care to elaborate?
    – user63623
    Oct 17, 2019 at 7:07

Will it work on all Unixes? Yes.

Is it a good technique to use? No. There are other techniques that are better. For example, proper use of unix groups and strictly controlled "sudo" configurations can achieve the same things.

I've seen exactly one place where this was used without problems. In FreeBSD it is traditional to create a second root account called "toor" (root spelled backwards) which has /bin/sh as the the default shell. This way if root's shell gets messed up you can still log in.

  • 3
    It is not just traditional, it is the default. The toor user is created on every single install so that if the user screws up the root account toor is still available. That being said, most people never set a password for the toor user account!
    – X-Istence
    May 6, 2009 at 0:13
  • This answer is wrong -- then and now. I am certain it did not and will not work on all variants of unix.
    – Astara
    Aug 28, 2014 at 0:14
  • In what way is it wrong? Which variants dont work?
    – TomOnTime
    Aug 28, 2014 at 4:30
  • With file-based name service maps (/etc/passwd, /etc/group), this works consistently on every UNIX I've seen. AIX or HP-UX (I forget which) would automatically add a second group named "group2" (and "group3," etc) with the same GID when the number of members in that group increased to make the line in the file longer than the OS maximum line length. I manually did that on the other one, and on SunOS, and Linux. Until we migrated to LDAP, that is. :)
    – dannysauer
    Sep 15, 2014 at 18:36
  • 1
    @TomOnTime It's not so much a matter of whether bad practice is prohibited, but more a matter of what is supported and tested by the vendor. I don't know of any unix or linux vendor that would support such usage. Given that it isn't likely to be tested, the consequences are untested and unknown. Any company following best practices will follow those supported by the vendor. Not doing so will open the door to lawsuits should problems result later on. It is asking for potential problems. To use such a feature, would require full testing of all needed paths. It would be very costly.
    – Astara
    Oct 20, 2019 at 11:41

I can't provide a canonical answer to your questions, but anecdotally my company has been doing this for years with the root user and have never had any issues with it. We create a 'kroot' user (UID 0) whose sole reason for existence is to have /bin/ksh as the shell instead of /bin/sh or bin/bash. I know our Oracle DBAs do something similar with their users, having 3 or 4 usernames per install, all with the same user IDs (I believe this was done to have separate home directories with each user. We've been doing this for at least ten years, on Solaris and Linux. I think its working as designed.

I wouldn't do this with a regular user account. As you noted, after the initial login everything goes back to the first name in the log file, so I think the actions of one user could be masqueraded as the actions of another in logs. For system accounts though it works great.


Are there unintended consequences to this practice?

There is one issue I am aware of. Cron does not play well with this UID aliasing. Try running "crontab -i" from a Python script to update cron entries. Then run "crontab -e" in the shell to modify the same.

Notice that now cron (vixie, I think) will have updated the same entries for both a1 and a2 (in /var/spool/cron/a1 and /var/spool/cron/a2).


Is this ability designed or is it just the way it happens to work?

Designed that way.

Is this going to be consistent across *nix variants?

It should, yes.

Is this accepted practice?

Depends on what you mean. This type of thing answers an extremely specific problem (see root/toor accounts). Anywhere else and you're asking for a stupid problem in the future. If you're not sure if this is the right solution, it probably isn't.

Are there unintended consequences to this practice?

It is general custom to treat usernames and UIDs as interchangeable. As a few other people pointed out, login/activity audits will be inaccurate. You'll also want to review the behavior of any relevant user-related scripts/programs (your distro's useradd, usermod, userdel scripts, any periodic maintenance scripts, etc).

What are you trying to accomplish with this that would not be accomplished by adding these two users to a new group and granting that group the permissions you need?


This is expected behavior on all distributions I've seen, and is a common trick that 'the enemy' uses to hide accounts with root access.

It is certainly not standard (I have not seen this in play anywhere), but there should not be any reason that you cannot use this in your own environment if you see fit.

The only gotcha that comes to mind right now is that this might make auditing difficult. If you have two users with the same uid/gid, I believe that you'll have a hard time figuring out which one did what when you are analyzing logs.

  • This is true. The initial login would register as a1 or a2 in /var/log/secure, but subsequent activities get logged as a1 no matter how you log in.
    – Tim
    May 5, 2009 at 19:08

Sharing primary group IDs is common, so the question really revolves around the UID.

I have done this before to give somebody root access, without having to divulge the root password - which has worked well. (although sudo would have been a better choice, I think)

The main thing I would be cautious about is things like deleting one of the users - the program may get confused and delete both users, or files belonging to both, or similar things.

In fact, I think that programmers probably Assume a a 1:1 relationship between user and UID, so there very well could be unexpected consequences with other programs similar to what I have described for userdel.

  • Sharing group IDs is not so common, I think, as having multiple users belong to a single group. There is a subtle difference. The key really is in the UID handling. Good point on deleting, though, which I will test out.
    – Tim
    May 5, 2009 at 19:05

BTW -- this question/answer updated for today's OS's.

Quoting from redhat: managing unique UID and GID Number assignments, it describes usage of UID and GID's and their management and how generators (ID servers)

must generate random UID and GID values and simultaneously ensure that replicas never generate the same UID or GID value. The need for unique UID and GID numbers might even cross IdM domains, if a single organization has multiple disparate domains.

Similarly, utilities that allow access to the system may behave unpredictably (same reference):

If two entries are assigned the same ID number, only the first entry is returned in a search for that number.

The problem comes when the concept of "first" is ill defined. Depending on the service installed, usernames may be kept in a variable sized hash that would return a different username based on inconsistent factors. (I know this is true, as I've sometimes tried to use 2 usernames w/one ID, one being a local username, and the other being a domain.username that I wanted to map to the UID (which I eventually addressed in a complete different way), but I could log in with "usera", do a "who" or "id" and see "userb" OR "usera" -- randomly.

There is an interface for retrieving multiple values of UID's from a group (groups with a single GID are designed to be associated with multiple UID's), but there is no portable interface to return a list of names for one UID, so anyone expecting the same or similar behavior between systems or even applications on the same system may be unhappily surprised.

In the Sun (now oracle) yp(yellowpages) or NIS(NetworkInformationServices), there are also many references to requirements of uniqueness. Special functions and servers are setup to allocate unique ID's across multiple servers and domains (example is the uid_allocd, gid_allocd - UID and GID allocator daemons manpage

A third source one might check is Microsoft's server documentation for NFS Account Mapping. NFS is a unix file share protocol and they describe how file permissions and access is maintained by the ID. There, they write:

  • UID. This is an unsigned integer used by UNIX operating systems to identify users and must be unique in the passwd file.

  • GID. This is an unsigned integer used by the UNIX kernel to identify groups and must be unique in the group file. MS-NFS-management page

While some OS's may have allowed multiple names/UID (BSD derivatives, perhaps?) most OS's depend on this being unique and may behave unpredictably when they are not.

Note -- I am adding this page, as someone referred to this dated entry as support for modern utils to accomodate non-unique UID/GID's... which most, do not.


I also don't know if it is a good idea or not, but I use the above behavior in a few places. Mostly it is for accounts that where used for accessing the ftp/sftp server and updating web site content. It didn't seem to break anything and seemed to make handling of permissions easier then it would have been with multiple accounts.


Just ran into a (rather obscure) issue stemming from the use of multiple accounts with the same UID, and thought I'd share it as an example of why this isn't good practice.

In my case, a vendor set up an Informix database server and a web application server on RHEL 7. During the setup, multiple "root" accounts with UID 0 were created (don't ask me why). I.e., "root", "user1" and "user2", all having UID 0.

The RHEL 7 server was later joined to an Active Directory domain using winbind. At this point, the Informix DB server could no longer start. Running oninit was failing with an error message saying that one "Must be a DBSA to run this program".

Here is what we found while troubleshooting:

  1. Running id root or getent passwd 0 (to resolve UID 0 into a user name) on an Active Directory joined system would randomly return either "user1" or "user2" instead of "root".

  2. Informix was apparently relying to a string comparison to check whether the textual user name of the user starting it was "root" and would fail otherwise.

  3. Without winbind, id root and getent passwd 0 would consistently return "root" as the user name.

The fix was to disable caching and persistence in /etc/nscd.conf:

enable-cache    passwd      no
persistent      passwd      no

After this change, UID 0 once again consistently resolved to "root" and Informix could start.

Hope this will be useful to someone.

  • I have a feeling that this worked and was not even entirely "frowned upon" back when UID's were 16-bit numbers and just used as a way to login to a machine. Similarly, I have a feeling this started changing with the introduction of UUIDs and GUIDs, at 128 bits / number specifically created at that size to make it very unlikely that two different users would end up with the same ID. This was for tracking, billing + licensing. As governments increase control of technology, requirements for unique ID's have increased. It's needed to peel away anonymity. No, I'm not paranoid, really! ;^/
    – Astara
    Jun 17, 2019 at 0:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .