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
