Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

My understanding of UIDs is that is a unique positive integer assigned by a Unix-like operating system to each user. Each user is identified to the system by its UID, and user names are generally used only as an interface for humans.

How can two users have the same UID, isn't this a conflict for my system and packages?

root@kdc:~# id test12
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~# id test13
uid=1005(test10) gid=1000(server) groups=1005(test10)
root@kdc:~#

I've added two users with same UID and GID: test12 and test13

The output of /etc/passwd:

client@kdc:~$ cat /etc/passwd | grep test12
test12:x:1005:1000::/home/test12:/bin/sh
client@kdc:~$ cat /etc/passwd | grep test13
test13:x:1005:1000::/home/test13:/bin/sh

I added the users by useradd -ou 1005 -g1000 username.

I got confused what is the purpose of this, and can it affect permissions and user logs etc. So now if a user is added with uid=0 and gid=0 will has privileges like a root account?

share|improve this question
    
Not sure about it, but I think the output is printing the UID of user "test10" in both commands. Why is doing that, I have no idea, but must be some user you created previously. –  darent Feb 27 at 15:41
    
as if its saying there is a user that has this id –  nux Feb 27 at 15:48
    
OK, I misunderstood the question. I thought that you created the users normally and the system assigned them the same UID. –  darent Feb 27 at 15:52
    
no man not normally , the question here , how the system accept unique uids –  nux Feb 27 at 15:54
    
Got it. Good question then, thanks for the explanation :) –  darent Feb 27 at 15:56
show 1 more comment

9 Answers

up vote 25 down vote accepted

The answer here is that Linux does not protect you from yourself.

If you really want to su root and go into the /etc files and give all the users the same UID, you can. It's just a text file.

But you really shouldn't and it will have unintended consequences.

share|improve this answer
2  
my question is why the system accept this ? –  nux Feb 27 at 16:28
31  
What do you mean "accept" it? How would it NOT accept it? this is like being a chef and asking why the soup allowed you to put too much salt in it. In terms of modern computing, you're probably used to an RDBMS mentality, where contraints on important things like IDs keep you from shooting yourself in the foot. Linux user IDs are much more primitive and have no internal checking or correction. –  Digital Chris Feb 27 at 16:32
4  
Right, and by using useradd -o you recognize that you're outside of the norm adduser. As @psusi mentioned, it creates two logins pointing to the same ID as far as file permissions etc. It probably also creates issues since that is not a normal use case and is no doubt untested with lots of packages. –  Digital Chris Feb 27 at 16:44
2  
If you want to shoot yourself in the foot, linux is perfectly willing to let you load the gun and pull the trigger. It's only an operating system, if you think you have a good reason to do something weird it's not going to second guess you. –  Shadur Feb 27 at 20:19
2  
@Josh of course it is, there are valid reasons to have multiple users with the same UID, see my answer for one example. –  terdon Feb 27 at 23:01
show 5 more comments

There are actually valid reasons for this. For instance, I used to work in a lab where we each had our own computer but our $HOME was in a shared drive exported by a server. So, my $HOME was

/users/terdon

Since the /users folder was actually not on my local machine but exported over NFS, for any analysis that was heavy on I/O, I would use data stored on my local hard drives so as not to burden the lab's network. To that end I, and everybody else, had two users: one that was system-wide and one that was local to the machine in question. The local user's home was

/home/localuser

However, I needed to have full access to my files whether I was logged in as terdon or as localuser and the way our sysadmin had implemented that was by giving both localuser and terdon the same UID. That way, I could freely manipulate my local files irrespective of which user I was currently logged in as.

share|improve this answer
5  
In support of this answer, it's worth noting that some setups such as virtual email hosting use this to great effect, i.e. a great number of virtual email accounts sharing a single UID - the documentation for the Dovecot mail server actually suggests this as an optional approach at wiki2.dovecot.org/UserIds#mailusers –  MThomason Feb 28 at 1:58
    
wouldn't chmod 666 have the same affects? –  staticx Feb 28 at 19:49
2  
@GIJoe that would allow both users to read/write but it wouldn't preserve ownership which could be a problem. Also, not all files can be set to those permissions (ssh keys for example) and it is not practical to need to play with permissions all the time. –  terdon Mar 1 at 8:07
add comment

Two users can have the same UID because it is just a number in a text file so you can set it to anything you want, including a value that is already used. As you have seen though, doing so is not a good idea.

share|improve this answer
    
how the system deal with users then ? sharing permissions –  nux Feb 27 at 15:47
10  
@nux, they are both the same user. They can just have a different username/password for the purpose of logging in. –  psusi Feb 27 at 15:48
4  
@bigbadonk420, the term "supported" is rather nebulous. It certainly is something you have always been able to do on unix systems and it used to be a fairly common backdoor to set up another user that has uid 0 so you can log in and effectively be root, without needing to know or change the password on the normal root user. –  psusi Feb 27 at 18:13
1  
@bigbadonk420 it is supported, there are cases where this is useful, see my answer for one example. –  terdon Feb 27 at 23:02
add comment

It's actually fairly common to have two users with the same ID. On FreeBSD, there are usually two users with UID 0: root and toor. Root uses the built-in /bin/sh shell, and toor uses a different shell, usually bash.

share|improve this answer
add comment

Unix systems & Linux generally do nothing to prohibit duplicates in the /etc/passwd file. The intent of this file is to associate a UID with a physical name that can be display by command line tools such as ls when user's are listing out files.

$ ls -n | head -5
total 986000
drwxrwxr-x.   3 1000 1000      4096 Feb 13 19:51 1_archive_sansa
-rw-rw-r--.   1 1000 1000    760868 Dec 16 08:21 2.18.x Database Scheme.jpg
-rw-rw-r--.   1 1000 1000       972 Oct  6 20:26 abcdefg
drwxrwxr-x.   2 1000 1000      4096 Feb 11 03:34 advanced_linux_programming

The other intended purpose of this file is to specify what shell a user will get when they login.

$ getent passwd saml
saml:x:1000:1000:saml:/home/saml:/bin/bash

A common attack vector on Unix type systems is to add lines such as these to a system's /etc/passwd file:

$ getent passwd r00t
r00t:x:0:0:root:/root:/bin/bash

$ getent passwd toor
toor:x:0:0:root:/root:/bin/bash

The role of the /etc/passwd file is NOT meant to solely track user accounts. The role of tracking username's and passwords is the responsibility of the /etc/shadow file. Files such as /etc/passwd and /etc/group are really meant to provide a human readable name when your system is listing files from disks.

Remember that your files are written to the disk using UID/GID's not actual names.

$ stat afile 
  File: ‘afile’
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file
Device: fd02h/64770d    Inode: 6560621     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/    saml)   Gid: ( 1000/    saml)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2014-02-27 15:54:21.852697029 -0500
Modify: 2014-02-27 15:54:21.852697029 -0500
Change: 2014-02-27 15:54:21.852697029 -0500
 Birth: -

Notice the Uid: and Gid:, the numbers are what's actually written to the disk!

share|improve this answer
add comment

In Linux, all users and groups are actually just numbers. That's what the output of the id command you posted shows.

The /etc/passwd file maps user names to user IDs (numbers) and in the example you have provide, you've simply mapped two usernames to the same user ID.

Effectively, you've created one user, test12, ID 1005, who also has a second username test13. However the system will map UID 1005 to the first username it finds, which would be test12

Linux "lets" you do this because there's no system to prevent you from doing this. /etc/passwd is just a text file, usernames are mapped to the UID found for their entry in that file, UIDs are mapped to the first username found in that file.

But what you've created is a confusing situation for other systams administrators; avoid it by changing the UID of test13

share|improve this answer
    
this is my test virtual machine man , my question is there a purpose to map two users for the same uid –  nux Feb 27 at 16:52
1  
The only purpose I can think of is to give a UID a second, aliased, username. But this is undefined behavior and not recommended. Really this is an undesirable situation: you're better off with a 1:1 relationship between usernames and UIDs –  Josh Feb 27 at 16:55
    
thats why i asked this question i needed to know , i felt that it is a confusing way –  nux Feb 27 at 16:58
    
It is confusing; that's why you shouldn't do it. It doesn't have a "purpose", it's more a misuse of the /etc/passwd file. But there's no means in place to prevent you from doing this. Does that make sense? –  Josh Feb 27 at 17:01
1  
a user mentioned that the goal is to have 2 logins point to identical filesystem permissions. –  nux Feb 27 at 17:02
show 1 more comment

The reason that this is allowed today, is simply because the system doesn't prevent it.

If this changed, then it would break those systems where admins have had a use for this feature, (see Terdon's example). So it has never been changed, and I don't think it ever will.

Originally there was only the passwd and group files, and they served their purpose. there was no adduser command, no addgroup, the files were edited by root using vi or ed.

There were a few quirks !

In order to remember the next user-id to use, it was common for admins to have a special user as the last line which had a user-name of ! (because ! was an invalid user name) and that entry was used to store the next user-id. Crude, I admit, but It worked! So why bust a gut making it more complicated, akin to agile development today.

There were known flaws. The main being, that it had to be world readable, so that utilities like ls could could map user-id => name. This meant anybody could see everybody's encrypted password, and all the users and id's in the system.

Some Unix systems began introducing a couple of shell scripts adduser addgroup, often these were ignored, because they were a inconsistent between Unixes, so most people just carried on with the manual edit.

It took quite a few years, before the shadow password file was invented, this provided a little more security, by hiding the encrypted passwords. Again, just enough complexity was added, but it was still fairly crude and simple. The utilities useradd and groupadd were introduced, which kept shadow and shadow- updated. To start with, these were often simple shell script wrappers around vendors proprietary adduser/addgroup utilities. Again it was just enough to keep going.

Networks of computers were growing up, people were working on several at a time to get jobs done, so admin of the passwd/group files was becoming a nightmare, especially with NFS, so in comes Yellow Pages also known as NIS to alleviate the burden.

It was becoming obvious by now that something a bit more flexible was needed, and PAM was was invented. So if you were really sophisticated and wanted a centralised, secure, unique-id'ed, all bells and whistles authentication system you would call out to a central server to authenticate, maybe a Radius server, LDAP server or Active directory.

The world had grown up. But the passwd/group/shadow files still remained for us smaller users/developers/labs. We still didn't really require the all bells and whistles. I guess the philosophy had changed a bit by now to, "If you were going to make it better, you wouldn't use it at all", so don't worry about it.

This is why I don't think the simple passwd file will ever change. There's no point any more, and it's just great for those £30 Raspberry Pi's with 2 maybe 3 user's monitoring temperature, and twitter feeds. OK, You just have to be a bit careful with your user-id's if you want them unique, and there's nothing to prevent the enthusiast from wrapping useradd in a script which first selects the next unique id from a database (file) to set a unique id, if that's what you want. It is open source after all.

share|improve this answer
add comment

There are identifiers that the operating system expects to be unique, but they are used for tracking hardware. The knowledge that a particular Universally Unique IDentifier corresponds to a hard drive containing system files may help it to continue operating if the hardware configuration changes. Microsoft calls these Globally Unique IDentifiers and uses them to track all Windows software. Ironically, these acronyms were poorly chosen.

From the perspective of the OS, most user and group identifier changes amount to changing its outside interface. It could function normally despite collisions; mainly what is required of the system users and groups is that they exist. It cannot know what the users require. In situations like this, the Unix philosophy is that the OS should assume the administrators know what they are doing, and should help them do it quickly.

share|improve this answer
add comment

The /etc/passwd file just maps symbolic usernames to the real userID. If you deliberately make two symbolic names that map to one userID then it will let you.

That doesn't mean it is a good idea to actually do it. Some people may have found very specific usage cases where they can take advantage of this feature, but in general you should not do it.

Linux (and other UNIXes) take the opinion that the administrator knows what they are doing. If you tell it to do something stupid then that's your own fault, in much the same way that if you tell your car to drive over a cliff you can't go to the manufacturers and ask why the car allowed you to do this.

share|improve this answer
    
why it was mentioned as a bug ? –  nux Feb 28 at 3:37
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.