Radu's answer is extremely informative here https://askubuntu.com/questions/376932/why-who-command-does-not-shows-root-as-a-logged-in-user However this makes me wonder "what is the exact definition for " logging in" in Linux?
I don't know if you'll ever find a precise definition that everyone agrees on. Maybe just "
/bin/login or equivalent". Everyone should at least agree that
su isn't a login though, since it doesn't replace the existing login on the terminal, and one of the defining features of a login is that only one person at a time is logged in on any one terminal.
My definition, which will probably be contested, is that "log in" means to start a new session, on a terminal (or X display) that currently has nobody using it. But what about when you create a new terminal? Launching an xterm doesn't feel like logging in even though it creates a new tty, because it doesn't ask for authentication (you authenticated at the start of the X session, or earlier if you used
Starting a new ssh connection, on the other hand, is definitely very login-like, even when it's not configured to use
/bin/login. Unless you specify a command to run on the remote instead of an interactive shell - an operation that requires authentication but doesn't feel like a "login" exactly.
The original question you link to is easier to answer because it's about something concrete (the
who command), instead of the philosophical question of what it means to "log in". The precise answer is that
who reports the contents of the
utmp file. If you want to know whether a specific action (like
ssh localhost -l root) will record an entry in
utmp, the answer is often "it depends".
xterm has options
+ut to control whether the terminal will be added to
screen, you can toggle the current tty's
utmp entry with CtrlA followed by L. The L stands for login.
For ssh, I don't see any dedicated option. After a few experiments, it seems that you get a
utmp entry if you create a tty, even if you run a non-interactive command on it (
ssh -t localhost w shows the
w in its own listing).
This sounds like as good an explanation as any I've seen.
excerpt from Wikipedia: http://en.wikipedia.org/wiki/Login
It is a common misconception that the noun login can be used as a verb. In reality, the term log in is a verb and refers to the process of identifying and authenticating the user, whereas the term login is a noun and refers to the credentials required to obtain access. For systems where a user must type in a username and password, the username and password combination is their login and the act of supplying these details for validation is then logging in.
Log in is a special kind of verb called a phrasal verb. A Phrasal verb is one comprising two words consisting of (1) a verb and (2) an another part of speech, either an adverb or a preposition. Because the phrasal verb log in is used so frequently, the space is often carelessly and incorrectly dropped.1
Also if you look through the definitions in the OpenGroup Base Specifications, The Open Group Base Specifications Issue 6.
The unspecified activity by which a user gains access to the system. Each login is associated with exactly one login name.
3.214 Login Name
A user name that is associated with a login.
The first step in the login process is authorization. This step determines whether the login is allowed or denied. In most cases, authorization requires authentication: the user who wants to log in supplies credentials (user name and password, user name and a computation based on a private SSH key, user name and Kerberos token, …) and the system determines whether these credentials are authorized to log in. Often, but not always, any user who completes the authentication process successfully is allowed to log in. An example of authorization that doesn't involve any authentication is when root runs
su to log in as a different user — root is always authorized to do that. An example of authentication that isn't sufficient to log in is when root is restricted to certain terminals, for example many system forbid root logins over the network.
The second step is to start a session. This always involves at least starting a process as the desired user, possibly the user's login shell as indicated in the account database. Other common steps include writing log entries, setting environment variables, setting resource limits, …