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.
