Image of the glider from the Game of Life by John Conway
Skip to content

Duplicate UIDs On Linux

This may be old hat for some, but I just discovered today that it is possible to have duplicate user IDs on the same Linux machine. The 'useradd' and 'adduser' commands will not allow it:

root@kratos:~# useradd -u 0 test_root
useradd: UID 0 is not unique

However, not to fear. Hand-editing the /etc/passwd file is possible, and further, giving the ability for a successful login. For example, here are the first 10 lines of my /etc/passwd:

root@kratos:~# head /etc/passwd
root@kratos:~# pwconv

I ran the 'pwconv' command to update the /etc/shadow file for the password aging information on the 'test_user'. Now, to test with a login shell:

root@kratos:~# passwd test_root
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
root@kratos:~# ssh test_root@localhost
test_root@localhost's password: 
test_root@kratos:~# whoami

As you probably know, Linux doesn't care much about the username itself, as much as it does the UID of the username. Further, when testing the account against the /etc/passwd file for existence, upon first successful pass is the winning account. That is why 'whoami' shows the 'test_root' account rather than the 'root' account.

Why would you do this? Doesn't this just seem silly? To be honest, the only solution I can see with multiple UIDs, would be for the root account as demonstrated above. This way, if you lock out the root account, say with PAM or otherwise, you have a "back door" root account that you can use. Unfortunately, this leads to bad overhead, and sloppy administration. Further, I've heard applications check for the username "root" rather than the UID "0" like they should, thus generating broken apps when using the backdoor account. Definitely, a better solution to this scenario would be proper delegation of the 'sudo' command via the /etc/sudoers file.

I would be interested on further insight for those who have encountered this scenario before. Please comment.

{ 20 } Comments

  1. John Myers | July 17, 2008 at 10:00 pm | Permalink

    useradd does allow creating users with duplicate IDs with the -o option

  2. John Gill | July 18, 2008 at 12:18 am | Permalink

    Only use I can think of is to have a way to log on with different default shells for the same user.

  3. Another John | July 18, 2008 at 3:41 am | Permalink

    On FreeBSD you have a special account called 'toor' that works in the way John Gill describes. See

  4. T Steffen | July 18, 2008 at 3:43 am | Permalink

    I used to work in a place ages ago where everybody had the same user id. This was on HP, but I guess Linux is broadly similar.

    For access restrictions, the UID is the only thing that matters. But you can still have separate home directories and profiles, because those are set based on the actual user name. Also the variable $USER can be used if necessary - as you have found out already.

  5. anonymous | July 18, 2008 at 3:53 am | Permalink

    @Another John:

    Yeah, the so-called "toor-user" is in NetBSD too.


    This has nothing to do with “back door” root account, but instead it is typically due different shells:

    root:*:0:0:Charlie &:/root:/bin/csh
    toor:*:0:0:Bourne-again superuser:/root:/bin/sh

    Of course in Linux it is Bash all the way down, so there is no real reason for this odd feature.

  6. anonymous | July 18, 2008 at 3:58 am | Permalink

    Oh, yes and one more thing:

    "Further, I’ve heard applications check for the username “root” rather than the UID “0″ like they should."

    You can not obtain any privileges with the UID/GID-combination. The names are just for convenience; I remember that the getuid() -man page was (once) decent on Linux.

    Perhaps you should reread about the standard UNIX/Linux DAC model. For multiple superusers, you need MAC or similar solution (think e.g. SELinux), as you probably are well aware of.

  7. anonymous | July 18, 2008 at 4:02 am | Permalink

    A third post certainly feels stupid, even though the aim is not to troll.

    A. A typo in the above; "without\with\ the UID/GID-combination".

    B. Perhaps you could blog about the shells in default Ubuntu install. Why on earth there is a valid shell for, say, man-pages? This is one of those things that are not "sensible defaults" and gives a serious messy feeling about Ubuntu's interiors.

  8. Jeff Schroeder | July 18, 2008 at 5:25 am | Permalink

    Editing /etc/passwd is pretty undesirable. If you mess it up, you pork your system. Don't do that unless you *really* know what you are doing.

    Use vipw as it won't let you save an invalid passwd file, or something along the lines of:
    usermod -o -u 0 hax0r

    The "-o" allows you to use non-unique uids and doesn't have a chance of hosing your system. Never try to be too clever, it will bite you in the end.

    To answer your question, what if you need to do something that you would normally do with group permissions, but using a group is not really an option? Even if it sounds ugly, it will pop up on the rare occassion.

    The solution is generally to use a duplicate UID even if it is discouraged.

    @anonymous: Take a look at this simple lockdown script I wrote for Ubuntu, it is intelligent enough to remove the login shells from many users who don't need it and works from Dapper+ :

  9. Tormod | July 18, 2008 at 6:09 am | Permalink

    "Further, when testing the account against the /etc/passwd file for existence, upon first successful pass is the winning account. That is why ‘whoami’ shows the ‘test_root’ account rather than the ‘root’ account."

    So if you log in as root (as opposed to test_root in your example) "whoami" will return "test_root"? If whoami is meant to "print the user name associated with the current effective user ID" that's a reasonable behaviour.

  10. grsjst | July 21, 2008 at 1:23 am | Permalink

    I suppose duplicate uid's may be helpful for nfs when the same user has differnt uid's on different machines.

  11. Fergus Doyle | July 23, 2008 at 3:34 pm | Permalink

    One reason to use it is if you are using a certain software package and you want to have say a "menu" log in and "shell" and maybe a reports login. Now what happens is depending on your username you get access to different functionality according to your .profile. But we still need to be careful about permissions because if we are accessing shared memory or stopping / starting processes we need to have the correct permissions. Sure you can do most of this through group permissions rather than user perms ions but shared memory can be more _troublesome_ on some versions of Unix not sure where Linux stands on this one though.

  12. Alex | July 27, 2008 at 5:39 am | Permalink

    I once tried this with a regular user, in order to have two KDE stored sessions, depending on if I was online or not. It apparently worked, but then subtle errors which I no longer remember happened down the way. I guess that the ambiguous name given the UID do mattered somewhere. It seemed a good idea at the time, though.

  13. rnd | August 1, 2008 at 4:34 pm | Permalink

    Actually I was thinking about utilizing this to create a second user with the same id as www-data/httpd/apache2 user so I could create a user who could log into a vsftpd chrooted session but be in the doc root with the correct user ID to automatically make files readable to the web server. Of course the real user running the Apache daemon would remain disabled for login. Does anybody foresee a major issue with this idea? Your feedback would be appreciated!

  14. rnd | August 1, 2008 at 4:36 pm | Permalink

    P.S. Sorry about posting from vista... I'm at work...

  15. AlexP | April 8, 2010 at 1:20 am | Permalink

    So i ran into this "occasion" where i am trying to figure out the proper way to do it, and my "scrappy" brain decided why not duplicate the UID and GID?...

    I am learning/setting up CentOS Server admin. I installed vsftpd and apache, and the problem was, if i made any changes or created a folder with the ftpsecure user via my ftp client then apache didnt have privileges to write to that folder unless i chmod 775 the folder opposed to keeping it at 755.

    So if my apache UID and GID were 46, i just created another user "example" and then placed the example above apache so it was found on the first pass.

    Now i can create folders via ftp and have apache(php) able to write to them.

    Although this works, i get the hunch its not save or stable?

  16. AlexP | April 8, 2010 at 1:20 am | Permalink

    I realize this post is almost 2 years old, but hopefully someone jumps back on it?

  17. Aaron | April 13, 2010 at 7:56 am | Permalink

    Not sure I follow. You want to create a folder that gives the apache user write access to it automatically? Probably best to use file ACLs. Check out the 'setfacl -d' command.

  18. Marco Ceppi | June 28, 2010 at 12:14 pm | Permalink

    AlexP: I used a similar hack for Tomcat - someone needed to upload and modify Tomcat configuration files, and upload webapps, without using SSH (They used SFTP) So I created a user with the same UID/GID as tomcat, as files are modified and written by either the user or tomcat the UID stays the same and permissions can be more restrictive.

    However this was, as I consider, a hack. I haven't seen any negative impacts but with enough brainpower and time I'm sure a better compromise could have been hatched.

    I don't recommend this for production environments.

  19. draeath | June 13, 2011 at 8:56 am | Permalink

    I've run into a case where the clamd packages were expecting the user clamav, and yet other software was insisting (eg replacing the config change on update) on it being clam. The best solution I found to prevent maintenance headaches was to make sure the clamav and clam users/groups have the same ID numbers.

    Since I did this, I have yet to have to go back and fix the thing after an update.

  20. Josef | December 5, 2012 at 8:03 am | Permalink

    I use this to have a second user with bash for sftp-clients.
    I use zsh as my shell and have it start in screen at login (so actually screen is my login shell) asd GUI sftp clients don't work that way. With a second [username]-sftp user with same UID and GID I can transfer files and they have the correct rights.

Post a Comment

Your email is never published nor shared.