@pid_eins post #31 links to post #30

@pid_eins congrats on the release! Great work 🎉

…the AF_VSOCK "CID" (which is like an IP address, i.e. an identifier for the local VM) you can specify a friendly machine name, if the VM in question is registered with systemd-machined. systemd-vmspawn sets things up that way out of the box, of course. That means, with current off-the-shelf systemd inside a VM and on the host you can now just do "ssh machine/foobar" to connect to a local VM called "foobar", via AF_VSOCK, i.e. independently of any fragile network.

…are in a pretty good position: we use libdw to generate the stack trace, running inside a local sandbox (since generating stacktraces means analyzing frequently corrupted, possibly differently privileged, complex data, which is hence security sensitive par excellence), and since the relevant distributions now ship minidebuginfo packages and are built with frame pointers enabled the default stacktraces you get this way are typically quite useful – without having to bother with gdb or so.

@pid_eins I really like your posts about this. Given the sheer number of highlights this time, though, would you consider collecting these in a more practical format somewhere? It can be a pain to scroll through Mastodon for this, and it presents the information much better than release notes.

I guess many of the systemd detractors don't even realize that /etc/os-release is a systemd-ism.

Over the years the failed acquired various fields. It no longer just describes the distribution a system was installed with, but on image based systems it describes the image itself. It gained fields for describing the end of support, and where to find the release notes. And it's extensible: various distributions add their own fileds (hopefully properly prefixed by a namespace prefix!).

Or in other words: when enabled the service will run as PID 1 in its own process namespace.

Up to this point we avoided exposing PID namespacing as part of service namespacing, following the thinking that service management should make stuff invisible and inaccessible, but not open "a new world", but unlike the other namespacing types PID namespacing is really about opening "a new world", with its own PID 1 and so on.

Or in even other words: we thought that PID namespacing is a concept…

…that the system is rebooted as often as really necessary but not more than that, in order to maximize uptime, and not annoy the user needlessly. After all, rebooting means disruption, and unavailability of the system's services.

With systemd v257 the systemd-logind service gained a new centralized knob for designating a specific "maintenance time" for systems via the new DesignatedMaintenanceTime= setting in logind.conf.

It takes a calendar time expression (in the same format…

Here are two examples using that:

varlinkctl introspect /run/systemd/io.systemd.Credentials

and

varlinkctl call /run/systemd/io.systemd.Credentials io.systemd.Credentials.Encrypt '{"text":"foobar"}'

The 2nd argument always specifies the entrypoint socket to talk to. In most cases where you call this locally that's the file system path of an AF_UNIX socket. However this can also be the path to an executable, in which case the executable is invoked and told via $LISTEN_FDNAMES (i.e.

@pid_eins can we pass file descriptors to local services?

Thus, if the same service gets started 5 times iteratively, it will have 5 different invocation IDs assigned. And if you want to pinpoint a specific invocation of a service, it's the invocation ID you can use to uniquely identify it. (Besides the use as metadata when logging the invocation ID is also passed via the env var $INVOCATION_ID to the services btw; and systemctl status also shows it these days.)

One could say that what the Linux boot ID does for the system…

These fields are consumed and acted on by systemd-logind, systemd-homed and other components of systemd.

One field is particularly interesting: it contains a field for the public SSH keys of an account (i.e. the stuff you traditionally find in ~/.ssh/authorized_keys). By making it part of the user record itself it can be accessed and used by SSH without access to the home directory of the user.

… but actually is just some malware that exfiltrates the password you type in?

Since this kind of attack scenario is not new, many OSes provide a "SAK" concept, which stands for "Special Attention Key". The idea is that there's a special key combination you can hit first, which no web page, or web browser, or app, or even desktop environment could possibly hook into that always brings you back to your *real* login screen, regardless where you are.

D-Bus' model is built around a central broker daemon, which is started during boot, but unfortunately relatively late (i.e. together with other, regular daemons instead of early boot or the initrd). However, systemd brings up the system as a whole and hence needs IPC from earliest moment on.

And then there are various components of systemd that the D-Bus broker relies on (i.e. consumes functionality of) and hence cannot themselves provide their services on D-Bus, …

But: they do have some disadvantages. They typically imply (not strictly, but typically) that they are built on OS vendor build systems instead of locally. This is different from the status quo ante, where the initrd is typically built on the deployed system (at least on generic distros), and thus highly adapted to the local system.

UKIs being vendor-built hence means they are a lot more rigid, less flexible than the traditional way. So far this meant you'd have to settle…

@pid_eins UKIs are fine, but systemd-stub churn every release makes it more of a liability than a stable foundation to build on.

Stuff like sysexts etc could poke holes in established security models similar (but restricted in scope) to how systemd poked giant holes into full disk encryption when it added DDI automount.

It's a massive effort to keep up with changes and validate them and it's pretty concerning. So you might end up not doing that, and end up with vulnerabilities in your product.

@pid_eins - Varlink reminds me of the IPC system we used at BlackBerry like 12 years ago. I guess the big difference was back then it was basically JSON with additional binary integer types. Not exactly like CBOR.

@pid_eins wait, distros could just just enable it and they don't? How come?

@pid_eins The shocking thing is that this was a requirement for Carrier Grade Linux two decades ago already.
When it comes to reliability and availability as part of dependable computing, our (distributed or not) systems have somewhat regressed as they were scaled up.

@pid_eins

You mean, like keeping old grub/lilo entries and kernels since forever?

@pid_eins (And do note that kernel is following suit with the new DRM panic stuff ;-)

@pid_eins So next time a BSOD goes round the world on a low res screen, Microsoft will finally plausible deniability, thus completing you evil plan 😈

At any time on a single systemd machine you'll have 1 system manager and 0…n user managers running. This model is built around the traditional UNIX security model: UIDs are the primary security concept of the system, and thus we give each relevant UID a service scope of its own.

While the original purpose of the per-user service manager is to provide functionality for actual human users logging in interactively people have been using the concept for other purposes as well:

It relies on TCP as network transport, which is great for remote operation around the globe but really sucks for local communication with a VM and similar, as it usually requires delegation of an address space, dhcp lease, dns and so on, which while manageable are certainly a major source of mistakes, fragility and headaches. In particular it means that logging into a system to debug networking doesnt really work since without working networking you cant even log in. Sad!

DDIs are supposed to carry dm-verity authentication information, i.e. every single access to them is typically cryptographically protected, and linked back to a set of signing keys maintained by the system (ideally in the kernel keyring). systemd uses DDIs for the system itself, for systemd-nspawn containers, for systemd portable services, for systemd-sysext system extensions, for systemd-confext configuration extensions and more.

@pid_eins suid programs executing in the environment of the parent process means that I might become root in a user namespace and get the filesystem view of the current mount ns. This won't work with your approach, will it?

@pid_eins This is very nice - especially having it provide a clean context, that saves a ton of headaches and sanitization I need to do when using "sudo" in other programs! (not like that's an amazing thing anyway, but occasionally it's useful and justified)
Only having run0 coloring / changing the output of the called command is not something I always like, but maybe that can be optionally disabled...

@pid_eins

Is there an equivalent to "sudo -e"?