Here's a blog story with links and very brief summaries of all those #systemd257 stories on Mastodon:
https://0pointer.net/blog/announcing-systemd-v257.html
Enjoy! And stay tuned for #systemd258!
=> More informations about this toot | View the thread
And that's it! After 37 installments I think I covered pretty much all the bigger things in the NEWS file with a story.
Of course, there's a lot more in this release. For the full list, consult our NEWS file:
https://github.com/systemd/systemd/blob/70bae7648f2c18010187c9cf20093155eaa26029/NEWS
Stay tuned so that you won't miss out on the #systemd258 series when the time comes for the next release!
=> More informations about this toot | View the thread
This is extremely handy, since it "just works" here. In fact, I switched over to this for my private VM needs entirely now.
(In related news, systemd-ssh-proxy now supports the AF_VSOCK "MUX" protocol too. This means it's now compatible not only with AF_VSOCK how it's implemented by qemu, but also with the implementations in Firecracker/CloudHypervisor)
=> More informations about this toot | View the thread
…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.
=> More informations about this toot | View the thread
3️⃣7️⃣ Here's the 37th post highlighting key new features of the current v257 release of systemd. #systemd257
In systemd v256 we added a small tool "systemd-ssh-proxy" whose job is to allow connecting to local VMs with ssh via the AF_VSOCK protocol (as opposed to AF_INET/AF_INET6). It acts as host-side counterpart to the guest-side systemd-ssh-generator that automatically binds sshd to AF_VSOCK.
In systemd v257 the functionality has been updated so that instead of specifying…
=> More informations about this toot | View the thread
With v257 networkd's DHCP logic can properly decode these fields now, and make them available for higher level code.
Note that systemd-resolved doesn't pick up this information and use it yet in v257, but that's on the TODO list for v258, now that the data is readily available.
=> More informations about this toot | View the thread
3️⃣6️⃣ Here's the 36th post highlighting key new features of the current v257 release of systemd. #systemd257
With the advent of DNS-over-TLS and DNS-over-HTTP a new set DHCP fields have been defined that can designate specific DNS servers with various protocol properties, in RFC 9463 ("DNR").
This is particularly relevant, since when connecting to a DNS server with encryption it's generally essential to know the Authentication Domain Name ("ADN") of the server to contact.
=> More informations about this toot | View the thread
To make sure that user records are truly portable between systems we opted for encoding the allowlist as part of the user record itself: when preparing a new user record the admin can precisely encode in it which of the fields a user is allowed to modify on their own.
Allowing unpriv modification of user records is not a new concept of course, classic UNIX allows this via "passwd" after all. But I think the flexibility of including the allowlist in the user record itself is particularly nice.
=> More informations about this toot | View the thread
With v257 this logic is relaxed: there's now a an allowlist of user record fields that the user may modify without admin consent, or in other words: any fields on that allowlist may be changed in a user record, and then passed to systemd-homed which will update the record and sign it properly – without requiring root privs. (Any fields outside of that allowlist may not be modified however).
Now, which fields shall be changeable without admin consent should itself be subject to admin's consent.
=> More informations about this toot | View the thread
…security credentials, but the user's account is protected by the system's security credentials: only the system can make changes to the user's account, i.e. change passwords, change resource settings, change real names and so on, because only the system can then sign the resulting new user record correctly.
Effectively this so far meant: to make any changes like this required admin consent: simply changing your account's password would require providing the admin's password too.
=> More informations about this toot | View the thread
…where user data is at best encrypted with a per-system/admin encryption key, and access control to user accounts is just something that protects the ability to log in, but not the user's data.
In continuation of this security focused theme, user records managed by systemd-homed are cryptographically signed: only accounts properly signed by a system-owned key pair can actually log into a specific system.
That means two things: first of all the user's data is protected by the user's…
=> More informations about this toot | View the thread
3️⃣5️⃣ Here's the 35th post highlighting key new features of the current v257 release of systemd. #systemd257
systemd-homed is the user/home area managed service of systemd. It's designed to provide very secure home directory management on Linux OSes. One fundamental idea is that the user's provided unlock credential (password, FIDO token, PKCS11 token) are actually what the encryption key for the home directory is derived of. This is of course fundamentally different from traditional UNIX, …
=> More informations about this toot | View the thread
…and with full privileges. OTOH updatectl is more of an interactive user-facing tool, that can be invoked without privileges. Hence, depending on your usecase you might prefer one or the other, but admittedly the line between the two are a bit blurry.
systemd-sysupdated has been contributed as part of GNOME's OS STF grant, where it's essential to have user controllable updater functionality available.
=> More informations about this toot | View the thread
… the systemd-update command line tool is augmented by systemd-sysupdated daemon that makes the functionality available via D-Bus, can keep track of multiple parallel transfers and more. It gained a client-side tool updatectl to interact with this.
This of course feels a bit redundant: why have the systemd-update tool and the updatectl tool, both which do the same stuff and can be called from the command line?
The systemd-update tool is mostly useful when directly invoking it from scripts…
=> More informations about this toot | View the thread
3️⃣4️⃣ Here's the 34th post highlighting key new features of the current v257 release of systemd. #systemd257
Back in v251 we added systemd-sysupdate too the systemd suite. It's a tool for updating block devices (such as partitions), specific files (such as sysext, confext, portable service or nspawn DDIs), or file system trees in a simple an atomic way.
So far it has been a command line tool only, that you can invoke from the shell, and that would do its thing. With v257…
=> More informations about this toot | View the thread
But hopefully sooner or later we never have to rely on it again, and can instead use idmapped mounts in all cases.
Features like this are just wonderful: they simplify the logic, speed it up, increase security and enable new functionality. How often do you get the chance to tick all those four boxes at once?
=> More informations about this toot | View the thread
…will be mapped transiently to the right dynamic UID/GID.
This also opens another door for us: we can eventually allow sharing of such directories between two DynamicUser=1 services that run with distinct UIDs: on disk all their files will be owned by "nobody", but each service they are associated with will see them as if they own them personally, even though all these services run under a different UID.
For compatibility with old kernels we retain the chown() logic for now.
=> More informations about this toot | View the thread
And that's awesome in this context: it means we never have to chown() anything: we can leave the inodes as is, but dynamically mount them to the right ownership in a trivial operation. Yay!
With v257 this is now hooked up. This not only brings efficiency, but also security: we made it so that the files on disk are now owned by the "nobody" user/group, i.e. the special UID/GID that the kernel uses for "unmapped" users/groups. Only during lifetime of the DynamicUser=1 service they…
=> More informations about this toot | View the thread
…on service activation if needed. It has worked like that ever since.
Re-chown()-ing is not ideal though. Effectively, in most cases it's sufficiently fast to not be annoying, but for services with very complex directory trees with millions of inodes this might come at a prohibitive time penalty.
On modern kernels there's new functionality to make this situation better: idmapped mounts. They permit that the UIDs/GIDs stored on disk are remapped before being made visible to applications.
=> More informations about this toot | View the thread
…context of DynamicUser=1: they allow such services to have persistent directories on disk, that are properly owned by the short-lived UID. Implementing this comes with some ugliness however: what happens if I reference some state directory from a DynamicUser=1 service today where it will get UID X assigned, and tomorrow when I start it again it will get UID Y assigned?
Our solution was pragmatic: when this happens we recursively re-chown() the referenced directories…
=> More informations about this toot | View the thread
=> This profile with reblog | Go to pid_eins@mastodon.social account This content has been proxied by September (ba2dc).Proxy Information
text/gemini