9

I mean, if two users have the same name, how does the system know that they're actually different users when it enforces file permissions?

This doubt came to my mind while I was considering to rename my home /home/old-arch before reinstalling the system (I have /home on its own partition and I don't format it), so that I could then have a new, pristine /home/arch. I wondered if the new system would give me the old permissions on my files or if it would recognize me as a different arch.

  • 12
    The simple answer is "it doesn't", because you're not supposed to have multiple users with the same username. – Ignacio Vazquez-Abrams Jun 20 '18 at 21:06
  • What if I send a file to a friend of mine that has my same username? Will he have broader permissions than another one with a different name? – Arch Stanton Jun 20 '18 at 21:10
  • 6
    UIDs, which are distinct from but usually associated with user names, are how this sort of thing is tracked. See the output of ls -n. – DopeGhoti Jun 20 '18 at 21:10
  • 5
    "Send" is too nebulous an operation to answer the question. Permissions only apply to a single system (of arbitrary size). – Ignacio Vazquez-Abrams Jun 20 '18 at 21:11
  • 1
    @IgnacioVazquez-Abrams This question actually came to my mind when I was considering to rename my home /home/old-arch before reinstalling the system (I have /home on its own partition and I don't format it), so that I could then have a new, pristine /home/arch. I wondered whether I would retain the same permissions on my files, or if the system would recognize me as a different arch. – Arch Stanton Jun 20 '18 at 21:17
  • 1
    I think the case you mention in your comment is interesting, about two users with the same username, but on different systems installed on the same machine, accessing the same files on a shared partition. Perhaps you could add it to the question? – Time4Tea Jun 20 '18 at 21:51
  • In Unix the user is a number, not a name. Different users, different numbers. – Thorbjørn Ravn Andersen Jun 21 '18 at 09:43
  • @ThorbjørnRavnAndersen "Different users, different numbers." Except when not. See e.g. root and toor in the BSDs. – user Jun 21 '18 at 13:39
  • @MichaelKjörling To the system it is the same user. – Thorbjørn Ravn Andersen Jun 21 '18 at 13:51
  • @ThorbjørnRavnAndersen True, but to the human they can very well appear as two different users. They certainly can have different passwords. – user Jun 21 '18 at 13:54
  • @MichaelKjörling Yes. But in Unix the user is a number... Not a name. – Thorbjørn Ravn Andersen Jun 21 '18 at 13:56
  • Relating: https://unix.stackexchange.com/a/287079/117549 – Jeff Schaller Jun 22 '18 at 11:02

4 Answers4

22

If you force there to exist multiple users with the same username, then there will be multiple entries in /etc/{shadow,passwd} with the same name:

$ cat /etc/passwd
...
a:x:1001:1002::/home/a:/bin/bash
a:x:1002:1003::/home/b:/bin/bash

# cat /etc/shadow
a:...:17702:0:99999:7:::
a:...:17702:0:99999:7:::

If you try to log in as that user, you'll log in as the first match.

$ ssh a@<host>
Password:
$ id
uid=1001(a) gid=1002(a) groups=1002(a)
$ pwd
/home/a

There will be no way to log in as the second user with the same name.

Note that Linux tracks users by their uid, not by their username.

It would be possible, however, to have two different usernames be the same user ID. Consider a different version of /etc/passwd:

$ cat /etc/passwd
...
a:x:1001:1002::/home/a:/bin/bash
b:x:1001:1002::/home/b:/bin/bash

Note that for both usernames a and b, the third column is 1001 -- that's the uid / user ID. Now, if user a or user b logs in (even with different passwords), they'll both be "user 1001", and show as user a from the OS' perspective. Here too, the first matching entry is the one returned (in most cases):

$ ssh a@host
Password: <a's password>
$ id
uid=1001(a) gid=1002(a) groups=1002(a)

$ ssh b@host
Password: <b's password>
$ id
uid=1001(a) gid=1002(a) groups=1002(a)

Both a and b are uid 1001 and will have access to the resources available to uid 1001.

mikemaccana
  • 1,793
  • 1
  • 12
  • 16
Andy Dalton
  • 13,993
  • why doesn't it check for duplicated usernames when creating a new one? – phuclv Jun 21 '18 at 02:18
  • 9
    Note that I think even the most baseline useradd will throw a fit if you try to add an existing user, so by 'force' here Andy pretty much means 'manually edit /etc/passwd and /etc/shadow which is very much Don't Try This At Home territory. – Shadur-don't-feed-the-AI Jun 21 '18 at 07:35
  • "There will be no way to log in as the second user with the same name." Couldn't you still call setuid with the second UID? Or even sudo -u '#<uid>' bash? – jazzpi Jun 21 '18 at 12:46
  • 1
    @jazzpi That might depend on one's definition of "log in". However, I could certainly see graphical login managers allowing this situation... – user Jun 21 '18 at 13:41
11

In Unix, users are identified by their ID (uid), which must be unique (in the scope of the local system). So even if it were possible to create 2 different users with the same name (adduser on my system refuses to do this, see this question for further information Can separate unix accounts share a username but have separate passwords?), they would need to get different uids. While you may be able to manipulate files containing the user information to match your criteria, every program is based on the assumption that uids are unique on the system, so such users would be identical.

EDIT: The other answer demonstrated a case where you have 2 different user names for the same uid - as far as the system is concerned though, this is like having two different names for the same user, so constructs like this should be avoided if possible, unless you specifically want to create an alias for a user on the system (see the unix user alias question on serverfault for more information on the technicalities).

The system uses these uids to enforce file permissions. The uid and gid (group id) of the user the file belongs to are written into the metadata of the file. If you carry the disk to another computer with a different user that randomly shares the same uid, the file will suddenly belong to this user on that system. Knowing that uids are usually not more than 16-bit integers on a unix system, this shows that the uids are not meant to be globally unique, only unique in scope of the local system.

3

I was considering to rename my home /home/old-arch before reinstalling the system. I wondered if the new system would give me the old permissions on my files or if it would recognize me as a different arch.

If you have a single-user system and do a reinstall with the same, or a similar distribution, it's very likely that your user account will have the same user id, and hence be the same user from the kernel's perspective. For example, the user created during installation has been UID 1000 on Debian systems as far as I can remember. Other systems might use some other number, but it's very likely to be some small-ish integer that's the same on every install.

The same applies to other users too (if you have any) since the UIDs are usually allocated sequentially. The third user created is likely to have the same UID as the third user created on another system. You'd need to take steps beforehand to make sure that the UIDs aren't being reused on both systems.

For similar reasons, anything using NFS will need to have a shared user database.

But in this case, since it's your personal system you can just login as root and run chown newuser. -R /home/olduser even if the UID were to be different.

(Windows systems are different, they generate that longish ID string that's more random. There, if you move a disk to another machine, the files will be seen owned by an unknown user, and you won't have access without using administrator powers.

Also, I said "likely" a lot in the above. There's no telling if some distribution behaves differently. Modern Linux also supports 32-bit UIDs, so while that's not nearly as long as Windows SIDs, there's still some space to use if one wants to have e.g. randomized UIDs. Usually, there's not much use for that, though. The system administrator is supposed to know what disks they attach to the system and to adjust the file ownerships accordingly, or make the mountpoint inaccessible to other users.)

ilkkachu
  • 138,973
1

Unix is a very old system, an era where storage capacities were very tiny, and everything — as well files as users — were identified by numbers. Names came later, after storage had grown a little bit.

A virtue of this system is that names are only labels hooked to the real handles: the numeric IDs. So you can have several names for one user (in editing /etc/passwd directly), as well as several names for one file (useful to store the file only once, but see it at several locations).

Limits are the system for the user, and the partition for the file.

I say that just to clarify, to explain why things are what they are.

I must confess I have never tried the opposite way — a same name with different IDs — I had always thought it was not possible. Is it? Not as a bug?

  • 1
    So are you saying that other file systems like NTFS or CIFS use usernames and not alphanumeric SIDS to store file owerships and permissions? – doneal24 Jun 21 '18 at 13:02
  • Not sure, but I believe it is the case, as alphanumeric SIDS did not exist when Windows was created — I still remember the day I bought Windows 286, which was the first graphic successor of MS-DOS … – ypouplard Jun 21 '18 at 14:26
  • 1
    @DougO'Neal: NT SIDs have two formats: a textual representation, and a 12-byte binary form. AFAIK, NTFS uses the latter internally, so it still uses numbers to identify users -- just very big numbers. :) – cHao Jun 21 '18 at 14:26
  • 3
    @ypouplard When Windows was created it was a single-user operating system. Didn't have any need to set file owership as the person sitting at the keyboard ruled all. – doneal24 Jun 21 '18 at 16:32