update password selection advice

marked this merge request as draft

changed the description

What happens when the root account is locked and one is dropped into rescue mode because of some hardware failure, mount point issues, etc.? (It's been a long time since I encountered that, I don't remember exactly what bad things need to happen to reach that point.)

changed the description

Yeah, I cannot remember either -- it used to just lock you out (forcing one to do the init=/bin/sh trick), but ISTR seeing rumours that one could use the password of a sudo-er.

That definitely would need to be confirmed before such a change of advice.

"Selecting an empty password here will lock the 'root' password" sounds weird to me. Changing the second "password" into "account" is what you had in mind?

The problem is that the account is not really locked, in that one can still log in to it using ssh, with a key, once configured. That made me think that saying the account was locked might produce false expectations. I've tried various wordings like "password based logins will not be allowed", but I've not found one I like much.

added 2 commits

1444cd05 - DO NOT MERGE THIS COMMIT - FOR TESTING ONLY
1d62c0c2 - fixup! root password advice: recommend none, or long

Compare with previous version

new screenshot here: https://openqa.debian.net/tests/185979#step/passwords/1

Also, I note that !6 is of course entangled with this

Another suggestion/clarification: "It will also add the user you setup in the next dialog ..."

added 1 commit

386d8eaf - fixup! fixup! root password advice: recommend none, or long

Compare with previous version

I note that Fedora has done stuff regarding locked-root and rescue, where the discussion was reported by LWN:

https://lwn.net/Articles/879272/

and it seems like they got to a point that they're happy with:

https://fedoraproject.org/wiki/Changes/FixRescueMode

apparently by relying on a package systemd-rescue-defaults that implements their required behaviour -- I've not looked at that to see what it does yet though.

Meanwhile, systemd has apparently added the ability to specify SYSTEMD_SULOGIN_FORCE as a kernel command line option, which change is included in version 254 (so this is now in testing).

Adding that to the kernel command line has the same effect as setting SYSTEMD_SULOGIN_FORCE=1, which in turn sets the --force option for sulogin, provoking the behaviour where having a locked root will give you a shell with no password required.

That in effect is just streamlining the init=/bin/sh trick, since one already had no security if grub is allowing the kernel commandline to be edited, but it does suggest to me that if we are to allow locked root (as we do), then we should set --force by default (as per !6), and then suggest that people that are upset by that either provide a root password, or configure GRUB to prevent editing the commandline, or probably both.

Describing those implications in a few sentences within the installer seems like it's probably not going to work, so we should probably have it all documented (on the wiki, say) and refer to it.

Also, I imagine there is a full spectrum of opinion about whether we should recommend setting or not setting a root password in the first place, so perhaps this is a case where we ought to go through a bout of consensus building on debian-devel before actually applying a change.

I've attempted to draft a truth-table of scenarios related to { locked-root + SYSTEMD_SULOGIN_FORCE=1 } - a condition I'm referring to as fail-open.

!6 (comment 432148)