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"?

Anyone knows where the kernel's github/gitlab project is? Would love to file an issue or placeholder revert PR, but somehow I cannot find it! Anyone?

(Yes, this is a joke, I am fully aware of the concept of mailing lists – as a historical concept from the 2005 era... Yes, I am too lazy to figuring out how to report this properly. Hence social media it is.)

@pid_eins don't forget, next time glibc enables a CVE it'll also be systemds fault for being linked to it :rofl:

Glad to see sane concepts landing anyway ^^

@pid_eins I'm sure they're going to make employee of the month!

@pid_eins LOL

that one can explain it in one sentence: send an AF_UNIX datagram containing READY=1 to a socket whose path you find in the $NOTIFY_SOCKET env var.

But apparently turning that sentence (which appears in similar fashion in the man page) into code is not trivial, hence this new example code.

Hence, copy away, the thing is MIT licensed. And the protocol has been stable for a decade, and I am pretty sure it's going to remain stable for another decade at least.

And I am pretty sure there's a lot of software you might be able to break given that they do not expect this case on the most basic of fs concepts.

Also note that these anonymous inodes are not actually as anonymous as one might think: because open fds appear in /proc/self/fd/ as magic symlinks you can easily get am fs path when you call stat() on will return you a zero inode type.

Double 🤯🤯

@pid_eins i can assure you i didn't think it's 7

…and risky dependency. But for the VM and full OS container case there's no real need to use SSH via the network: these things run on the local system, hence why bother with IP? To address that we are adding a small generator (that means: a plugin for systemd that generates units on the fly, based on system state, configuration) which binds SSH to a local AF_VSOCK socket in a VM, and to an AF_UNIX socket in a container. You can then use these to directly connect to the system without involving…

Link is here: https://github.com/systemd/systemd/pull/29748

@pid_eins super cool. NVMe-oF ftw! I'm actually looking for a way of trimming down some of the dependencies in systemd-udevd and udevadm to make it even smaller for an super small inirtd. I only want systemd-udevd to initialize local storage devices for my used case. The Fedora systemd-udevd is dynamically linked to a large systemd .so is there a way of building it against smaller systemd libs like libudev etc.?