Notices by Lennart Poettering (pid_eins@mastodon.social), page 4

… will be automatically called whenever the shared library they are placed in is loaded into a process (which means at process startup, before main(), or at dlopen() time) or when they are unloaded from a process (which means at exit() time, or dlclose() time).

At first, from the outside the concept seems kinda OK: it has this C++'ish RAII feeling to it to: whenever a library is initialized in can initialize some fields, and whenever deinitializes it can release them again.

But of course ELF constructors fuck that all up, because they get started before main() does its first step even, after all. It takes any control away we have in scheduling precisely when to do what.

And people do terrible things in ELF constructors: load configuration, check if kernel APIs are available (which typically means looking at /proc/, /sys/ or some other API VFS), pre-opening some fds, and so on. All these are things you really don't want to do before things are properly mounted, …

When pondering whether we should start linking to some external library in systemd, I usually spend some time looking at the library's sources, to understand the quality of the code. While coding style differences are fine, there are certain red flags that make libraries unsuitable for use in systemd, or that indicate questionable quality of the code.

Red flags like this are for example absence of OOM guards on malloc(), absence of reasonable error propagation,

1️⃣5️⃣ Here's the 15th installment of posts highlighting key new features of the upcoming v256 release of systemd.

systemd integrates with many components of the OS. Due to this it links against various external libraries. Generic distributions – which typically enable all features a package provides – usually have to deal with relatively large dependency trees in cases like this.

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!

1️⃣3️⃣ Here's the 13th installment of posts highlighting key new features of the upcoming v256 release of systemd.

ssh is widely established as *the* mechanism for controlling Linux systems remotely, both interactively and with automated tools. It not only provides means for secure authentication and communication for a tty/shell, but also does this for file transfers (sftp), and IPC communication (D-Bus or Varlink).

It also doesn't bother with a boot loader, since containers after all share the same kernel, there's no boot loader involved anymore. But in systemd we have sd-boot after all, which is a modern boot loader with many security features we need to work with. Per-container TPMs are also not really a thing.

Hence, in a recent systemd version we added systemd-vmspawn. It's a small wrapper around qemu, which has the point of making it as nice and simple to use qemu as it is to use nspawn.

And life has gotten so much better with it.

(Much of the work to get vmspawn up to speed for use in the integration test suite was implemented by Codethink btw, supported by the STF).

And that's all for now. Let's see if I'll manage to do a 10th installment soon.

With v256 vmspawn is relatively complete now. For example it now registers with machinectl, also supports credentials, sd_notify, and so much more.

At this point, for my daily work it's now as trivial to boot a relatively fully featured VM (with TPM, SecureBoot, and all that fancy new-fangled stuff) as it is to to run a full OS container, and all I have to do is replace "n" by "vm" in the command line I use.

We also started to switch over much of systemd's test suite to use vmspawn.

The idea is that we provide a roughly command line equivalent interface to VMs as for containers, so that it really is as easy to invoke a VM as it already is to invoke a container, supporting both boot from DDIs and boot from directories.

And one thing in particular we have a focus on here: that the integration points that make it so nice to use nspawn are also available in vmspawn, wherever we can possibly do that. i.e. credentials, sd_notify, and all that other stuff.

… maybe not quite as popular as docker, but it conquered many other areas, for example build systems and more.

There's one facet nspwan is particularly good at: we use it to showcase new integration features between the host systemd and containers. nspawn for example natively supports propagating credentials down to its payload, or supports sd_notify() ready notfications for the service manager in the payload. It allows binding a host user into the container via --bind-user=, or…

9️⃣ Here's the 9th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.

I am sure you are aware of systemd-nspawn, systemd's minimal container manager focussed on full OS containers, that can boot up a Linux image from an OS in a disk image or from a directory. systemd-nspawn was originally a development tool, to make it easy for us to develop the service manager without constantly having to reboot.

Nowadays it's a lot more than that, …

… authenticated OS images via dm-verity/DDI and there's so much more.

Now, I personally use nspawn daily, for developing systemd, testing integration and many other aspects and a lot more. But sometimes it's not enough for my work. For example, because nspawn directly transitions into the service manager it doesn't go through an initrd, so it cannot be used for test an initrd, even though that's a crucial part of developing an OS.

@mxk we kinda have that now with mountfsd/nsresourced, see earlier installment of this series. Not entirely polished yet.

1️⃣ So let's try something new. As we are closing in on tagging systemd v256-rc1, let's see if I manage to post a brief mastodon item about major new features of the upcoming release, every few days until the final release of v256. I figure not everyone reads NEWS files, even if curious. Hence let's start today with the 1st post: the new .v/ directories. You know those .d/ directories that are quite popular in low-level Linux packages these days? While .d/ dirs never have been formalized properly…

2️⃣ Here's the 2nd installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.

This time we'll talk about encrypted credentials. Credentials are these little pieces of information that you can pass into systemd systems and into system services. They can carry secrets but also other kinds of parameters. One key feature is that they can be encrypted while at rest, locked against the system's TPM…

6️⃣ Here's the 6th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.

In the 2nd installment of this series we have already discussed system and service credentials in systemd a bit. Quick recap: these are smallish blobs of data that can be passed into a service in a secure way, to parameterize, configure it, and in particular to pass secrets to it (passwords, PINs, private keys, …).

5️⃣ Here's the 5th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.

I am pretty sure all of you are well aware of the venerable "sudo" tool that is a key component of most Linux distributions since a long time. At the surface it's a tool that allows an unprivileged user to acquire privileges temporarily, from within their existing login sessions, for just one command, or maybe for a subshell.

"sudo" is very very useful, as it…

This has led various people to revisit the problem and come up with alternatives: most prominently there's probably OpenBSD's sudo replacement called "doas". While it greatly simplifies the tool and removes much of the attack surface, it doesn't change one key thing: it's still a SUID binary.

I personally think that the biggest problem with sudo is the fact it's a SUID binary though – the big attack surface, the plugins, network access and so on that come after it it just make the key problem…

… allows users to operate at minimum privilege: do most of their work without privileges but temporarily acquire them where needed, all without leaving the shell workflow, integratable with shell scripts, pipelines and so on.

sudo has serious problems though. It's a relatively large SUID binary, i.e. privileged code that unprivileged users can invoke from their own context. It has a complicating configuration language, loadable plugins (ldap!), hostname matches and so on and so on.