Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

9 Answers 9

up vote 9 down vote accepted

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.

share|improve this answer
    
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 '09 at 18:58
    
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 '09 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 '09 at 19:10
    
This answer is not valid today. –  Astara Aug 28 at 0:13

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.

share|improve this answer
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 '09 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 at 0:14
    
In what way is it wrong? Which variants dont work? –  TomOnTime Aug 28 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 at 18:36
    
But it's a bad idea in /etc/passwd and should basically never be done - including the "toor" thing. If someone's worried about screwing up root's shell, they have bad config management practices that should be fixed first. ;) –  dannysauer Sep 15 at 18:39

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?

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
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 '09 at 19:08

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

share|improve this answer

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.

share|improve this answer
    
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 '09 at 19:05

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.