Which is which
User name is an ambiguous term that could refer
- to a formal user ID string known to some system, or
- to a display name like
John Smith
.
For that reason, we have more specific terms like login name, which informs us that this is the character string that is used for logging in, like jsmith
, and not John Smith
.
User ID also serves this purpose, but it is ambiguous against a numeric user ID. That has to be clear from context. For instance in Unix, users don't usually deal with numeric user IDs; if a prompt asks for a "user ID", people just know that they aren't supposed to enter 1003
but jsmith
.
Display name (also called the real user name) informs us that this is a name of some software object (such as a user account) used for referring to it in user interfaces and program output such as diagnostic or debug messages. The implication is that a display name is not necessarily unique among such objects and cannot be used as a key to unambiguously refer to an object. It is literally for display purposes only. A "display name" is not necessarily a user name; that has to be established by the context. Anything that can have a name can potentially have a display name.
In traditional Unix, the /etc/passwd
file associates your numeric user ID with the login name (the textual user ID), and with a display name.
Changing and consequences
The chfn
utility is used for changing the display name aka real user name and related information. Doing this should have no consequence.
Changing the textual user ID aka login name requires privilege; root
can edit the password file to edit this. The effect will be instant: the new name will appear anywhere in the system where numeric user IDs are displayed as their text equivalent. For instance, if someone lists a directory using ls -l
and that directory contains files owned by that user, they will immediately see the new name, since the ls
program picks it out of the password database.
The change will break or potentially break various things in the system, and so is a bad idea:
- Firstly, if the new name clashes with another one, that's obviously very bad; I'm mentioning that for the sake of completeness. Let's assume that it's not the case.
- Let's also assume that it's not the case that some user's name is changed without their knowledge, leaving them unable to log in.
- The remaining problem is that in the file system there are likely configuration files which encode the textual user ID: both in their path names, and in their contents. These, of course, continue to refer to the old user ID which no longer exists in the password file. The name change is not complete unless all of these are hunted down and repaired.
- The problem can be further compounded if a new password file entry is created which matches the old name. Those configurations now refer to a valid user, but the wrong one.
As an example
- let's consider that the
sudo
utility exists in the system and is configured via the /etc/sudoers
file. Suppose the /etc/sudoers
file grants user bob
the privilege to run some dangerous administrative command with superuser credentials.
- Now suppose we rename
bob
to robert
in the password file and don't update this entry. Now robert
is not able to run that command any more; the sudoers
file grants the privilege to bob
not to robert
.
- Next day, a new user is added and happens to be called
bob
. This bob
now has the privilege to run that administrative command as root.