On Tue, Nov 26, 2019 at 9:48 AM Chris Adams <linux@xxxxxxxxxxx> wrote: > > 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. Good point. > 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. Yeah I forget the rationale for this. Since there's no bootloader lockdown, and it's trivial to just add systemd.debug-shell=1 I can get a tty with root user active and not even need a password, for any target, including multi-user and graphical. -- Chris Murphy _______________________________________________ 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
