Multiple *NIX Accounts with Identical UID

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.

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

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

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

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

Solution 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?