Bdtyktl

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.

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.

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!

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.

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

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.

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.

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.