Processes are running instances of executable binaries. Each process, similarly to each file etc., belongs to a certain user. (It's a bit more complicated because there are various user IDs for a process, but most of the time they are the same.)
A terminal line (tty) can be opened by any process at any time, just as a process can open/create a file, a TCP socket and so on. There's nothing special in terminals in this regard.
It's an ancient user-level concept that there exists an utmp/wtmp database keeping track of logins. Graphical login managers update the records beloging to the entire graphical login (makes sense more-or-less), and terminal emulators voluntarily update (or not) the records belonging to the given terminal line (this, in my opinion, as detailed in https://bugzilla.gnome.org/show_bug.cgi?id=747046, doesn't make any sense whatsoever). This comes from the days when terminal were real terminals instead of graphical emulators, sure it made sense to keep track of who's logged in from where.
It's in my opinion an obsolete, bad tradition to say that opening a graphical terminal emulator means "logging in", or that a log entry should be created for open terminal windows/tabs and that who
and similar utilities should report this.
Utilities like who
print the information based on these more-or-less properly maintained utmp/wtmp files, which is again of pretty limited usability and reliability.
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.
Best Answer
That is not a technical difference but an organizational decision. E.g. it makes sense to show normal users in a login dialog (so that you can click them instead of having to type the user name) but it wouldn't to show system accounts (the UIDs under which daemons and other automatic processes run) there.
Thus a border is defined or rather two ranges for the UIDs for the two groups. In openSUSE the file
/etc/login.defs
contains these lines:and