On Thu, Dec 10, 2020 at 5:40 AM Benjamin Berg <bberg@xxxxxxxxxx> wrote: > > Hi, > > so, the other day we had a major regression in the PAM stack[1] that, > unfortunately, ended up hitting rawhide and the Fedora 33 testing (not > stable) repository before being unpushed. > > In this case it was easy to work around as SSH was still working fine. > But, it seems that rescue mode requires having a root password set, > which we do not always do during the Fedora install. > > > So, I think we should have an obvious way for users to enter recovery > mode even with a locked root account. > > Currently rescue.service is executing "systemd-sulogin-shell" which in > turn runs "sulogin" (part of util-linux). A workaround is to > set SYSTEMD_SULOGIN_FORCE=1 in rescue.service, but that just disables > authentication entirely. > > I suppose to improve this, we would need a kind of "sudologin" that > accepts any user in the "wheel" group. Or maybe some other more rigid > requirement like configuring the first admin user that was created. > > Anyone has a good idea on how to solve this? I solve it with early debug shell using boot param systemd.debug-shell=1 but that presents a root login on tty9 without needing a password. I'm under the impression authentication services aren't even available for emergency or rescue targets (?). I also wonder what happens if we move to systemd-homed and whether that can start sooner and provide the ability to use rescue target? Or if it starts late enough that it can't be used for rescue and then also what that means for non-root use of rescue because with systemd-home, there are no (human) users in /etc at all. -- 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