Re: usrmerge breaks POSIX
Vincent Lefevre <vincent@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: