[Pkg-shadow-devel] Bug#801846: Be sure string entered for root shell is an executable file

[積丹尼 Dan Jacobson]

retitle 801846 Be sure string entered for root shell is an executable file
thanks

Recalling the events of that fateful day,

# history |grep -C 2 chsh
 9980  Sat, 23 Sep 2017 19:08:48 +0800 grep nobod /var/lib/dpkg/info/base-passwd.*
 9981  Sat, 23 Sep 2017 19:09:22 +0800 s /var/lib/dpkg/info/base-passwd.preinst
 9982  Sat, 23 Sep 2017 19:09:56 +0800 man chsh
 9983  Sat, 23 Sep 2017 19:10:45 +0800 chsh -s '' nobody
 9984  Sat, 23 Sep 2017 19:11:12 +0800 chsh -s /bin/bash nobody
 9985  Sat, 23 Sep 2017 19:15:14 +0800 chsh -s  nobody

And the next day I found myself locked out of the system.

You see every few months the 'nobody' account gets changed back to
nologin by some upgrade, however I want to use it for testing, so I
change it back.

Looking at the chsh man page

       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.

Well I have an idea:

Yes keep the policy

    unless the invoker is the superuser, and then any value may be added.

But *please* do a test -x (or the equivalent C etc. code) on the string the superuser enters.

That way one can be sure what he enters is at least executable.

Or, if that is asking too much, at least do a test -f.

Or please explain the value of nonsense strings there.

In this case I ended up with

root:x:0:0:root:/root:nobody

OK for people in this situation, who discover the next day their system
is no longer usable, how to recover?

As reboot(8) is no longer available, the only way to reboot is manually
pressing the power button. I hope you have physical access to your
computer, and are not continents away.

OK, now at the Debian boot menu choose a recovery kernel item.

Now at the login prompt, type root and root's password.

Fortunately at this point we see:

sulogin: failed to execute nobody: no such file or directory

and we are given a root shell prompt,

if we do
# chsh
at this point, we will get
chsh: PAM: Authentication failure

Not to worry, we can still use an editor, e.g., vi,
to change
root:x:0:0:root:/root:nobody to
root:x:0:0:root:/root:/bin/bash

and save the file. And our troubles are over.
One can now hit ^D to continue to boot.

OK. Looking back, of all the components mentioned, on sulogin(8) is
smart enough to let us in. One is particularly disappointed with chsh,
which I recall was invented with the main goal of not letting the user
accidentally mess up /etc/passwd, e.g., with ed(1).

P.S., I wonder what would happen if one ended up with
root:x:0:0:root:/root:/usr/sbin/nologin
root:x:0:0:root:/root:/bin/false

He would then probably need to edit /etc/passwd from GRUB... (tricky and
details beyond the scope of this report) or boot from a live USB stick
and mount the disk and edit...

Anyway, reviewing again

    unless the invoker is the superuser, and then any value may be added.

Well at least for root editing root, this is a bad idea. If he really
wants to enter nonsense, he could just use an editor.