Once upon a time, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> said: > On Tue, Nov 26, 2019 at 8:36 AM Chris Adams <linux@xxxxxxxxxxx> wrote: > > > > Once upon a time, Michael Catanzaro <mcatanzaro@xxxxxxxxx> said: > > > On Tue, Nov 26, 2019 at 8:03 am, Chris Adams <linux@xxxxxxxxxxx> wrote: > > > >How does that work with single-user mode, rescue mode, etc.? > > > > > > I assume single-user mode does not work. Rescue mode certainly does > > > not work. It asks for a root password, but root account is locked. > > > > That should be considered a bug IMHO... > > I brought this up ages ago. Basically emergency.target and > rescue.target have a hard requirement on root, and there aren't enough > services present to authenticate some other user (I guess?). And on > Workstation, it was long ago decided to not require setting up a root > user at install time *if* an (admin) user were setup. And that was > followed up more recently by eliminating the install time user setup > entirely, on Workstation edition. > > So...it's a difficult problem to solve. Mayyyybee systemd-homed is in > a position to solve this by having early enough authentication > capability by rescue.target time that any admin user can login? You can't guarantee that a non-root admin user even exists at single/rescue mode time, since they could all be network authentication. I'd suggest switching back to not requiring a password for single/rescue mode by default; there's not a default boot-loader password requirement, so it's not like the single/rescue root password can't be bypassed already. I actually had that as part of my personal setup scripts for a while, until now systemd removed the unit files and went to an undocumented wrapper binary. There should be a documented way to enable the password requirement (and then how to handle it, setting a root password, setting a boot-loader password, anything else required). But it is really IMHO kind of silly to have it there by default. -- Chris Adams <linux@xxxxxxxxxxx> _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
