Vincent Lefevre <vinc...@vinc17.net> writes: > On 2024-02-15 14:14:46 -0800, Russ Allbery wrote:
>> and pkexec is essentially a type of sudo and should be unavailable to >> anyone who is using a restricted shell. > The pkexec source doesn't say that the goal is to check whether > the user is in a restricted shell. So far as I am aware, the only purpose served by /etc/shells historically and currently is to (a) prevent users from shooting themselves in the foot by using chsh to change their shell to something that isn't a shell, and (b) detect users who are not "normal users" and therefore should have restricted access to system services. See shells(5), for example: Be aware that there are programs which consult this file to find out if a user is a normal user; for example, FTP daemons traditionally disallow access to users with shells not included in this file. > Also note than even in a restricted shell, the user may set $SHELL to a > non-restricted shell. This is generally not the case; see, for example, rbash(1): It behaves identically to bash with the exception that the following are disallowed or not performed: [...] * setting or unsetting the values of SHELL, PATH, HISTFILE, ENV, or BASH_ENV > Moreover, /etc/shells also contains restricted shells. That definitely should not be the case and any restricted shell that adds itself to /etc/shells is buggy. See chsh(1): The only restriction placed on the login shell is that the command name must be listed in /etc/shells, unless the invoker is the superuser, and then any value may be added. An account with a restricted login shell may not change her login shell. For this reason, placing /bin/rsh in /etc/shells is discouraged since accidentally changing to a restricted shell would prevent the user from ever changing her login shell back to its original value. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>