-
-
Notifications
You must be signed in to change notification settings - Fork 109
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow logging in to rescue/emergency shell as root #526
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #526 +/- ##
=======================================
Coverage 70.57% 70.57%
=======================================
Files 3 3
Lines 469 469
=======================================
Hits 331 331
Misses 138 138 ☔ View full report in Codecov by Sentry. |
Should those drop-ins be included in initramfs (when generated in VM) too? Or maybe they already are there? |
Yes, they should. Dracut module? |
757ef06
to
9e612aa
Compare
|
9e612aa
to
958f43d
Compare
Should this be conditional on the VM not being |
Similar issue may apply to other VM too. Can you make it specifically for hvc0 console only instead? |
But actually does other consoles matter here? Isn't rescue/emergency started only on the primary console (as configured with |
It should be indeed. I can check. |
958f43d
to
af904b8
Compare
Addressed much more simply by explicitly setting |
e9dc9ed
to
7043815
Compare
45bd08f
to
f9c1fdf
Compare
I'd like to have a test for this feature, I can write one, but I need few primitives for it:
|
|
In Qubes OS guests, the console is _always_ the Xen console. There are _never_ untrusted entities with access to this under _any_ circumstances. The only supported way to get access to this from a VM is the admin.vm.Console service, which is (by design) equivalent to root access in the destination VM. Other consoles, such as a USB serial console, are not supported as domU consoles under Qubes OS. Therefore, set SYSTEMD_SULOGIN_FORCE=1 to tell systemd-sulogin-shell to pass --force to sulogin(8). Since the root account is locked in Qubes VMs, this causes sulogin(8) to allow login as root without a password. Use TTYPath= to enforce that the console is, in fact, the Xen console and not some other console, in case the assumption in the previous paragraph turns out false for some reason. This will break if the Xen drivers are not included in the guest kernel config, but an HVM guest with Qubes tools but no Xen drivers is not a supported configuration.
f9c1fdf
to
ecdb763
Compare
I tested this. |
In Qubes OS guests, the console is always the Xen console. There are never untrusted entities with access to this under any circumstances. The only supported way to get access to this from a VM is the admin.vm.Console service, which is (by design) equivalent to root access in the destination VM.
Therefore, set SYSTEMD_SULOGIN_FORCE=1 to tell systemd-sulogin-shell to pass --force to sulogin(8). Since the root account is locked in Qubes VMs, this causes sulogin(8) to allow login as root without a password.