The kernel doesn’t know anything about users other than their numerical ID as a tag on certain things (processes, files). It doesn’t have a notion of “log in”, that happens in user land.
The program that handles the login process (
login on a text mode console, a display manager on a graphical console, a daemon such as
telnetd for remote logins, etc.) first authenticates the user and performs other tasks. PAM is often used; it has many capabilities related to authentication, logging, user databases, etc. The last step of the login process (when successful), after the program has switched from running as root to running as the desired user, is to invoke the login shell.
The login shell is determined from the user account database. There are several types of user databases; the most common ones are
/etc/passwd (or, rarely, some other file configured through NSS), which is a simple text file found on the local machine, and NIS and LDAP which are networked databases used on networks where accounts can be used from multiple machines.
Users can change their shell with the
chsh command for local accounts, with
ypchsh for NIS accounts, or with
chsh.ldap for LDAP accounts. In some places, the
chsh command is set up to work with whatever account database type is in use. Users are only allowed to switch between shells that are listed in the file
/etc/shells; this is both a security measure (users whose shell isn’t listed are presumed to have restricted accounts and can’t change) and a safety measure (changing to a non-existent or restricted shell could effectively lock the account). The administrator can change any account’s login shell by running the
chsh command or by editing the database directly.
On a normally-configured system, useful shell programs will be listed in
/etc/shells and those programs will work. (1) is technically true because the login shell can vary (the user or administrator can call
chsh at any time) even if it normally doesn’t, and of course launching any program involves having the kernel load the program file and will fail if the file doesn’t exist or is corrupted.
The login program runs the login shell with argument 0 set to the program name with a dash
- before the name. For example, if the login shell is
/bin/bash (the full path is necessary, no lookup in
$PATH is performed), then argument 0 will be
-bash. Argument 0 is normally the program name; the extra dash tells the shell to act as a login shell. Login shells run extra files on startup, e.g.
~/.profile; see Difference between Login Shell and Non-Login Shell? for more details about this part.
This multiple-choice exam isn’t well-designed because each option could be construed as true.
(1): it is indeed the case that the login shell is determined each time the user logs in. It is also true that the kernel decides on whether the shell is available during the login process. So technically (1) is true (and technical correctness is the best form of correctness, right?). But (1) is very misleading because the kernel doesn’t decide what the login shell is as such, it doesn’t even have a concept of login or shell.
(2) is not true in general since it is possible for different users to have different login shells. However there are setups where for a reason or another all users have the same shell — for example, heterogeneous networks where accounts are shared between machines and the only shell that is guaranteed to be available everywhere is
(3) is probably the intended answer, because
/etc/passwd is one place where the login shell can be configured by the administrator. However
/etc/passwd should not be edited directly, but via the
vipw command or via a command such as
chsh. Furthermore, non-local accounts aren’t stored in
Lets check some facts:
echo $SHELL. Now logout and login again.
echo $SHELL. Rinse, wash, repeat. Same answer every time.
The login shell is derived from the contents of
/etc/passwdfor all users. The value set in that file will be the value of the login shell for each user on the system. It is is possible for a user to run another shell, but it will not be their login shell without the value being set in
You can verify this by trying the command from various shells that you run manually:
bash -c "get-shell" sh -c "get-shell" zsh -c "get-shell"
All of these commands will give you the same output no matter which shell you run them under because the value for the login shell is not determined by what shell the user chooses to run but the one set for them in
Note if your system does not have
get-shellyou can substitute
getent passwd $(whoami) | cut -d: -f7inside the commands above to determine the user login shell.
This would depend heavily on the knowledge level of the administrator. Editing the
/etc/passwdfile requires knowledge of how to launch a text editor as root and the dexterity not to mess up even a single character in the file. While a ninja might pull this off, an administrator who reads
man chshwould see that is the program to adjust login shells:
chsh is used to change your login shell
If at least one of the answers above is true, this must be false.