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
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
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
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
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
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
- Next day, a new user is added and happens to be called
bob now has the privilege to run that administrative command as root.