Finally had a go at solving one of my biggest pet peeves with booting up Linux, having to add console=ttyS0 or console=hvc0 or console= to the kernel command line to get output on the serial console. With https://github.com/systemd/systemd/pull/41387, systemd-stub will now try to auto-detect whether a single virtconsole or serial console is attached without graphics output and append console= to the kernel command line automatically so you get output on the serial console automatically.
Remote
daandemeyer
@daandemeyer@mastodon.social
mastodon 4.8.0-nightly.2026-10-060 Followers
0 Following
16 Posts
Joined January 23, 2024
Replying to
I got inspired to implement this when I was playing around with bpftrace and systing and got annoyed that the files written by these tools were owned by root instead of my own user. Now I can run "run0 --empower bpftrace" and be sure that any written files are owned by own user instead of root.
Replying to
This is hooked up into nspawn via a new --private-users-delegate= switch to delegate N uid ranges into the nspawn container. With this we're very close to making nested nspawn work but this requires a few more changes to nspawn which will come in 261. I'm also hooking this up to mkosi so we can finally boot VMs and containers from directories unprivileged and without /etc/subuid. vmspawn also learned to boot from a directory using nsresourced in v260.
Replying to
@funkylab Instead of changing to root, we keep the current uid/gid and instead give it full ambient capabilities (https://man7.org/linux/man-pages/man7/capabilities.7.html) That's sufficient to pass all kernel privilege checks (disregarding LSMs). To pass polkit checks, we run the "run0 --empower" session with the new "empower" group as an auxiliary group and we ship a polkit rule to allow all actions for users in the "empower" group.
Note that this won't work if a tool checks for uid 0 instead of capabilities.
Replying to
@xogium Currently podman / docker don't nest within nspawn for the same reason that nspawn doesn't nest within nspawn (kernel mount shenanigans). Once we fix that you'll be able to run nspawn, docker and podman nested in nspawn (I think, there may be more issues with getting podman/docker running).
If you want to run unprivileged podman/docker within nspawn they'll need to integrate with nsresourced and mountfsd (instead of using newuidmap/newgidmap like they do right now).
Replying to
@wolf480pl Processes of the same user should be able to send signals to it yes. I actually consider that a feature. Currently, managing a subprocess invoked with run0 or sudo is a pain because you can't stop it except by messing with input pipes or TTYs passed through to the subprocess.
Replying to
@swick I just landed a refresh to chaseat() in systemd so it takes separate root and directory file descriptors as part of the InodeRef prep work. The only annoying thing about that is you can't easily check if a directory file descriptor is a child of another directory file descriptor. You have to walk upwards to check which is just horribly slow.
Replying to
@felixs @funkylab A debugger will be able to attach just fine. I've opened https://github.com/systemd/systemd/pull/39839 to clarify that other processes of the selected user will be able to mess with the empowered session.
So using run0 --empower gives malicious processes a vector to infiltrate the system. But so does sudo -E PATH or using sudo to execute anything in your home directory or using sudo -s, ....
Replying to
@samueldr So I'm already reworking this to pick the right index on x86 since they're statically allocated there. You're right that on arm we can't really know for sure. I kept it for now to pick ttyAMA0 if we find a single serial console.
As for the graphical console, you're of course right that this breaks if the uefi firmware can't detect the graphics output. I guess I could make it opt-in to avoid breaking existing use cases.
Replying to
@wolf480pl Effectively it's up to the user to decide if they're OK with their application running under "run0 --empower". If you're in an environment where you don't want the user to be able to mess with the empowered session via signals, then you should not use the --empower switch.
Replying to
@juliank @nik @pid_eins This isn't a new privilege escalation mechanism. All this option does is make some already existing features more easily accessible. I encourage you to take a look https://github.com/systemd/systemd/pull/39495 to see how trivial the PR introducing --empower was.
Replying to
@nik @juliank @pid_eins We disagree that the option is simple and innocent looking. Users have to go out of their way to type --empower to get this functionality. I doubt anyone will be doing that by accident.
We do acknowledge that if you leave one of these sessions open and switch back to it that it can be hard to figure out if you're in a regular run0 session or an empowered one. https://github.com/systemd/systemd/pull/39882 improves on this by adding a custom color, for empowered sessions.