Bug#806852: debian-installer: Rescue/Emergency shell unusable with locked root account
Package: debian-installer
Severity: normal
Dear Debian Installer Developers,
Currently if a user chooses to lock the root account during
installation, they are in for an unpleasant surprise when attempting
to fix boot-time issues using a rescue/emergency shell. In this
case, the user will be presented with the following message:
Cannot open access to console, the root account is locked.
See sulogin(8) man page for more details.
Then boot will either continue or fail without running a root shell
(based on whether the system is usable without intervention).
This issue was reported against util-linux, which previously carried a
patch to unconditionally allow passwordless root login through
sulogin, in bug 789950.[1] The util-linux portion of the issue was
fixed when util-linux upstream added the "--force" option to sulogin
to provide this behavior.[2] However, the issue still remains for
users, since none of the init systems or init scripts call sulogin
with this option.
Unconditionally adding "--force" to every invocation of sulogin is not
an ideal solution, since it presents a security issue for kiosks and
other computers which are not physically secure if users can provoke
an emergency shell during boot (perhaps ^C during routine fsck?).
However, this was the previous behavior, so it may be considered an
acceptable risk by some/many.
This is a tricky issue to fix without unconditional "--force", since
it requires coordination across multiple packages. Andreas Henriksson
presented the current thinking in Comment 63 of bug 789950[3],
including having d-i install an override snippet for systemd to use
the "--force" option when root is locked via the installer. This
seems like a very clean solution for systemd, but, of course, it
doesn't address the other init systems or init scripts (such as
checkroot.sh) which call sulogin. It may also cause issues for users
who lock or unlock the root account after installation, if they expect
unconditional login or users not expecting unconditional login when
choosing the option during installation.
After considering the issue a bit, the best alternative that I could
come up with would be to create a convention for marking the root
account as locked-but-emergency-accessible or
locked-and-always-inaccessible in passwd/shadow (e.g. by using a
particular symbol in the password field to denote either case) then
updating the init systems and init scripts to check this condition
before deciding whether to invoke sulogin with "--force" (or,
alternatively, to carry a Debian-specific patch to get this behavior
by default in sulogin, similar to the previous situation for better or
worse). But, of course, adding such a convention is a lot of work to
implement and document, and introduces meaning where there was none
before, which is not ideal.
If anyone has other ideas, or if the general consensus is to only
worry about the systemd case (and make the others unconditionally use
--force or risk breakage), at least for now, that would be fine by me.
Thanks for considering,
Kevin
1. https://bugs.debian.org/789950
2. https://github.com/karelzak/util-linux/pull/200
3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789950#63
Reply to: