Multiple *NIX Accounts with Identical UID

Question

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:

a1:$1$4zIl1:5000:5000::/home/a1:/bin/bash
a2:$1$bmh92:5000:5000::/home/a2:/bin/bash

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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).

Answer 5

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?

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.