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
add comment

8 Answers 8

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
add comment

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
add comment

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
add comment

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
add comment

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
add comment

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
add comment

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
add comment

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
add comment

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.