Lennart Poettering

⛵ I write software. ⛵

Public Key

npub1rk2uxtv6nk262nucavh259t085a8rhzfaj3vjc9jhzvkyav0rnqqxqzenj

NIP-05 Address

pid_eins_at_mastodon.social@mostr.pub

Profile Code

nprofile1qqspm9wr9kdfm9d9f7vwkt42z4hn6wn3m3y7egkfvzet3xtzwk83esqprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmd62udf6

Publishing to

relay.noswhere.com

Author Public Key

npub1rk2uxtv6nk262nucavh259t085a8rhzfaj3vjc9jhzvkyav0rnqqxqzenj

Show more details

Last Notes

2024-08-15 08:25:35

- reply

@npub1eh4…8h0k ah interesting. I indeed was not aware it wasnt just a concept with relevance only to those deeply invested in a 2015 era derivative container world.

2024-07-21 17:03:00

- reply

@npub1d45…8efx they love grub too much and how things where done in 1999...

2024-07-20 12:44:39

- reply

And it's a shame that commercial distros do not hook into that, and the boot stack of them hasn't changed in more than a decade, is laughably bad at security (unsigned initrds, ffs!) and robustness, and the if you have boot assessment enabled at all turn it into a fantastic DoS (by showing you a boot menu instead of reverting to a working boot choice).

2024-07-20 12:40:58

So, if you ask me what my takeaway from the Crowdstrike issue is, I'd say: boot counting/boot assessment/automatic fallback should really be a MUST for today's systems. *Before* you invoke your first kernel you need have tracking of boot attempts and a logic for falling back to older versions automatically. It's a major shortcoming that this is not default behaviour of today's distros, in particular commercial ones.
Of course systemd has supported this for a long time:
https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/

2024-07-19 12:26:03

As I understand the BSOD today became more popular than ever, truly becoming mainstream and reported about all over the news. Of course, in systemd we are ahead of the curve, as usual, and if you too want to experience your very own BSOD we have your back. Enjoy:
https://www.freedesktop.org/software/systemd/man/latest/systemd-bsod.service.html
Finally no need to feel left out again, just because you use Linux! 💖💘💝

2024-06-29 12:17:53

- reply

@npub1rml…xa6t journalctl --grep=... exists (or -g)

2024-06-27 21:33:49

- reply

Intended usecase for this: one UKI synthesizing three menu items: one for regular boots, one to activate storagetm mode, and one to trigger a factor reset. (or any other combo a distro desires)
Some things we still need to hash out, but I am quite confident that this design might be closed to what we'll merge into systemd-stub in the end.

2024-06-27 21:31:34

- reply

… and dealing with side-cars. And there's no nice way to choosing one of multiple cmdline choices in the boot menu.
I decided to do something about this now. here's a WIP PR: https://github.com/systemd/systemd/pull/33512 – it allows baking multiple alternative kernel command lines into a UKI, and the idea is that the boot menu then offers all of them to the user, synthesizing multiple boot menu entries from a single UKI.
It's a reasonable simple approach.

2024-06-27 21:28:55

You might know the UKI concept we introduced a couple of years ago, i.e. the unified kernel image. You glue kernel, initrd and some other metadata into one UEFI PE binary, so that it can be secureboot authenticated as one, and be measured as one.
It has many benefits to do things that way, but it also comes at one drawback: you bake in a single kernel cmdline, and in sb mode there's no way to use any other (well unless you use cmdline addon files, but that involves signing stuff separately, …

2024-06-18 14:06:33

- reply

@npub1hfq…7rhw btw, i am not sure why involve systemd-tmpfiles with that though? Just call "rm -rf /home"? requires same privs, and is shorter?

2024-06-18 14:03:21

- reply

@npub1fp2…trxj `rm -rf /home` is deutlich kürzer btw, brauch man kein systemd-tmpfiles für?

2024-06-14 11:28:33

REMINDER! All Systems Go! 2024 CfP ends TODAY! Don't forget to submit your proposal NOW!
→ https://cfp.all-systems-go.io/all-systems-go-2024/cfp
See you in Berlin!

2024-06-12 11:24:23

- reply

@npub1pta…55nl fixed.

2024-06-12 08:21:57

- reply

@npub1yp6…ua2t ah, thanks! fixed!

2024-06-12 08:15:13

Hey, I blogged again. I did a post with a listing of the first posts in a series of serieses of posts highlighting key new features of systemd v256. And now I am posting here about the post with the listing of of serieses of posts. Enjoy!
https://0pointer.net/blog/announcing-systemd-v256.html

2024-06-11 16:13:04

- reply

I also submitted two talks to the Linux Plumbers Conference 2024 MC "Kernel ↔ Userspace/Init/System Management boundaries and APIs". Here too the CfP ends soon! Make sure to submit your own talks *quickly*! It's time!
→ https://lpc.events/event/18/contributions/1681/
See you all in Berlin + Vienna!

2024-06-11 16:10:40

Today, I submitted two talks to All Systems Go! 2024 in Berlin – the best Low-Level Linux Conference around! The CfP ends this week! ⏱️ Hence, hurry 🚀! Please make sure to submit your own talk quickly – before it is too late! 🏎️💨
→ https://cfp.all-systems-go.io/all-systems-go-2024/cfp 🏃💥
(In case you wonder, my two talks are an update on systemd + TPM stuff, and about the Varlink IPC)

2024-06-11 12:18:31

- reply

This is the last episode of this post series for v256 I guess. We have now gone through 16 major features of the upcoming release, and the final v256 final release is imminent.
Please have a look at the full NEWS file for more features, in particular all the smaller ones, which are also super interesting:
https://github.com/systemd/systemd/blob/main/NEWS
And thank you very much for your time! I intend to do a similar series for v257 once it comes closer.

2024-06-11 12:16:19

- reply

If you want to know more about the capsule concept, please see https://www.freedesktop.org/software/systemd/man/devel/capsule@.service.html

2024-06-11 12:15:11

- reply

… it via the `system-run --capsule=…` switch. And you can issue commands on and introspect the capsule's service manager via `systemctl --capsule=…` and so on.
You can stop a capsule and start it again later if you want, the capsules home directory will survive. Once you are done completely with the capsule's data, use `systemctl clean --all capsule@<somename>.service` to get rid of the home dir and everything else.

2024-06-11 11:56:47

1️⃣6️⃣ Here's the 16th installment of posts highlighting key new features of the upcoming v256 release of systemd.
(Sorry for dropping the ball on posting these for a while!)
The last feature I want to discuss in this series of postings is the new "capsule" concept of systemd v256.
systemd can be invoked in two contexts: as a system manager, i.e. PID 1, where it manages, well, the system. And as a user manager where it runs services for a specific user.

2024-06-10 14:05:40

REMINDER! All Systems Go! 2024 CfP closes this friday! SUBMIT SOMETHING TODAY! Hurry!
https://fosstodon.org/@allsystemsgo/112592429536504055

2024-05-28 09:54:37

- reply

… when the release function for the relevant contexts is called again.
And that's really all I'd ask for. This is great, because it means consuming code can carefully schedule when and in which context it wants to start making use of the library, and thus when it shall be initialized, and when it doesn't need it anymore, and when it shall be deinitialized again.

2024-05-28 09:28:46

- reply

When systemd's main() function is started it then goes through a careful process of setting things up, i.e. establishing mounts, making things writable, loading security policies, initializing certain devices, RNGs, and so on, loading configuration and many many other things. This is carefully scheduled to be done in the right order, since after all we cannot assume that things are already set up for us, we have to do the setup *ourselves* after all.

2024-05-28 09:15:16

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,

2024-05-27 11:18:41

- reply

@npub1n8c…kpqk in systemd we have this C code for this:
https://github.com/systemd/systemd/blob/main/src/basic/terminal-util.c#L1725

2024-05-17 13:32:14

Kernel breaking userspace episode nr. 43858262:
https://github.com/torvalds/linux/commit/a1912f712188291f9d7d434fba155461f1ebef66
Hacking around it:
https://github.com/systemd/systemd/pull/32892

2024-05-15 14:00:36

- reply

For now the spec sits in systemd's repository. We intend to add them to the uapi group's repository soon though, as this really is supposed to be something not only systemd provides, but any software that is in a similar situation and uses dlopen() to gracefully import a fixed set of external libraries.
And that's all for now. Stay tuned for episode 16 soon.
(Sorry for not keeping up the pace btw, currently at a conference)

2024-05-15 13:59:00

- reply

All our binaries now contain an ELF "note" that can be processes in a similar way as regular ELF dependencies.
The format of these notes is described here:
https://github.com/systemd/systemd/blob/main/docs/ELF_DLOPEN_METADATA.md
There's now work ongoing to process this data automatically at rpm and dpkg build time, so that we get the best of both worlds: "weak" dependencies and proper metadata to declare them consistently.

2024-05-15 13:53:06

- reply

We have been doing this since quite a while, so that in v256 22 of our dependencies have been reworked like that.
This has the benefit that on a typical system the systemd binary itself only pulls in the C library (including libm), libmount, libselinux, libaudit and libseccomp.
Net result: we have a tiny required dependency footprint, but can still provide a large feature set, if the optional deps happen to be installed.

2024-05-15 13:48:07

- reply

systemd is often used in smaller environments, i.e run in containers, or in the initrd or similar. Hence a large dependency tree is problematic.
Hence in systemd we started to turn a large number of our dependencies from regular ones to dlopen() ones: instead of always requiring some shared library we only load it the moment we need it. This means we can gracefully degrade our feature set if certain libraries are not available.

2024-05-15 13:46:22

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.

2024-05-13 13:55:14

- reply

@npub1r9c…8j5a indeed! fixed!

2024-05-13 13:55:07

- reply

@npub1src…nehn indeed! fixed!

2024-05-13 13:52:58

- reply

And that's all for now, stay tuned for episode 14 soon.

2024-05-13 13:52:37

- reply

1. you have a fully encrypted root fs, with /var/ being placed on the root fs too
2. you have an immutable root fs, but /var/ is mounted writable.
In both these cases using /var/ as the path to search the backing block device for will work, while using / instead would not work for the 2nd case.
Also note, that this mechanism is automatically disabled when a destructive operation is used (i.e. an existing key slot shall be wiped), for robustness reasons.

2024-05-13 13:46:56

- reply

… detect such tricks, and refuse operation. In systemd we thus started to make more and more use of diskseq, for example via /dev/disk/by-diskseq/ device symlinks, or by referencing block devices via their diskseq numbers whenever possible. This works is incomplete currently, there are gaps at various places (for example, there's no userspace API to query the diskseq number from a mounted file system that is backed by a block device).

2024-05-13 13:38:19

1️⃣3️⃣ Here's the 13th installment of posts highlighting key new features of the upcoming v256 release of systemd.
This one is going to be quick one. Previously, you had to specify a block device name when invoking systemd-cryptenroll, to specify which encrypted volume to enroll your PKCS11/TPM2/FIDO2 device to. This is now optional. If no device is specified, then the tool will now automatically look for the device behind the /var/ directory and operate on that.

2024-05-10 14:18:56

- reply

@npub1kvs…zrev yeah, of course the old verbs continue to exist and do what they always did.

2024-05-09 19:24:32

- reply

@npub1jn4…66wl nobody is taking sudo away. It's about offering something better for OSes that don't have to care about legacy so much.

2024-05-09 12:49:58

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).

2024-05-08 11:06:59

- reply

@npub1l2t…uafu it doesn't show up in melpa if I do M-x package-list-packages however… Seems MELPA is hosed on Fedora Emacs?

2024-05-08 10:23:16

Even though Fedora probably is kinda popular among developers, it sometimes baffles me what is and what isn't packaged in Fedora.
I mean come on, how is it possible that there's no meson mode packaged for emacs on Fedora?
I mean, it's pretty obvious: if Fedora wants to be taken seriously as a developer platform, I think it's pretty obvious that this is a glaring omission, like no other! 🤓

2024-05-08 07:12:17

- reply

@npub1mm7…f09s we increase the version number when we do a new release.

2024-05-08 06:35:31

- reply

…out what to precisely do.
Hence, in your mind, please rewire "systemctl suspend" to now become "systemctl sleep".
And that's all for now. Stay tuned for installment Nr. 13.

2024-05-08 06:28:19

1️⃣2️⃣ Here's the 12th installment of posts highlighting key new features of the upcoming v256 release of systemd.
Putting a PC to sleep is complicated business and there are different mechanisms available to achieve this on Linux. Broadly speaking there is suspend-to-ram and suspend-to-disk, as well as combinations of this: one where we suspend to both, and one where we first suspend-to-ram and then later change to suspend-to-disk, if we have slept for a long time, or the battery is running empty.

2024-05-07 20:26:07

Look at this:
https://blogs.gnome.org/chergert/2024/05/07/system-extensions-from-flatpak/
Love it! 👌

2024-05-07 14:33:53

- reply

@npub193y…k4jm yes, typo.

2024-05-07 14:33:34

- reply

@npub1n3y…e9yh most of our releases if similar numbers of big features, it's just that previously I didn't post mastodon stories about them, and you had to read the NEWS file instead.

2024-05-07 08:24:50

- reply

@npub1ku3…qwn9 yeah, the "systemctl enable --now" line is independent of the ownership declaration for the device.

2024-05-07 07:46:58

- reply

… and declare ownership the same way.
And that's all for now. I hope to post installment 12 soon, there's still so much great stuff to cover!

2024-05-07 07:43:48

- reply

Hence, with this new Property= field you can nicely define via .link files which network service shall manage the matching devices.
This is particularly useful as systemd out-of-the-box ships with a bunch of .link files that match devices created by systemd-nspawn, systemd-vmspawn and systemd-nsresourced. These .link files have been updated to clearly indicate that these interfaces are supposed to be managed by networkd, and nothing else.

2024-05-07 07:41:28

- reply

Recap: .link files configure various settings on network devices that are more property of the device itself – as opposed to .network files which configure settings that belong to the network you then attach to it. .link files are a udev concept (they are also interpreted if you use NM hence!), while .network files are a networkd concept. At any time there are zero or one .link files and zero or one .network file applied to a network interface.

2024-05-07 07:39:08

- reply

This allows running multiple services side-by-side, and clearly tell each one which interfaces they shall manage. Of course they might still fight for the devices that are not tagged like this, but at least in the networkd case we should be safe, since by default it will not try to manage an devices it has no configuration for.
In systemd v256 we now made it possible to configure this udev property (or any other in fact) via the Property= field in .link files.

2024-05-07 07:35:38

- reply

…sure that there's exactly one service that manages each interface, so that they don't fight for ownership of the network device, trample on each other's feet and undo each other's settings.
To improve the situation in systemd v255 we introduced a udev property

2024-05-07 07:34:16

1️⃣1️⃣ Here's the 11th installment of posts highlighting key new features of the upcoming v256 release of systemd.
There are multiple network management services in popular use on Linux. In systemd we ship systemd-networkd, and of course think it's the best choice. Weirdly, some people disagree though, and that creates problems of ownership: you either have to use one or the other network management service (i.e. *either* systemd-networkd OR NetworkManager), or you have to carefully make…

2024-05-06 09:30:02

- reply

@npub1rrq…6gtd yeah, not convinced though. Doesn't protect the bits that need protection the most: the fs data structures. It's simply on the wrong layer. It's like you try to build a skyscraper on quicksand.

2024-05-06 08:27:44

- reply

@npub1ey9…xdrw gnome OS for example. And there are more that aren't that public I guess.

2024-05-06 08:00:06

- reply

@npub1wy5…5jkc No.

2024-05-06 07:53:57

- reply

@npub1hhn…dy07 just read the posting in full? it's answered there.

2024-05-06 07:51:27

- reply

This makes it really nice to try out new things: you can just overwrite files in /usr/ and /etc/, play around with them, and afterwards you just atomically flush out your modifications, and are back in the original immutable state.
This functionality has been added by the Flatcar OS folks, who'll probably be the first to showcase this in their distribution.
And that's all for now. Stay tuned for installment #11, hopefully in the next days.

2024-05-06 07:50:49

- reply

…because that is after all comprehensively forbidden on multiple layers of the software stack. That of course makes it harder to tinker with the system, and that sucks to some degree.
With v256 we are thus opening up things a bit: even though the primary focus of these tools (and of our general idea of what an OS should look like) is true immutability, there's now a new --mutable= switch to systemd-sysext/systemd-confext.

2024-05-06 07:50:03

- reply

Any inode in these trees can be traced back to a cryptographically signed layer, and thus the source and vendor they come from. If you ask me it's *the* way how to develop modern operating systems with strongest security but retaining modularity to some degree.
Developing in a purely immutable world is sometimes a bit harder than in a traditional world: you cannot just go and modify some file and see if that works, …

2024-05-06 07:49:31

- reply

In particular systemd-sysext has become quite popular on immutable OSes (by which I mean the ones that provide cryptographic immutability via dm-verity, not things like ostree where the immutability is mere convention) to provide a certain level of modularity to an otherwise rigid file hierarchy.
With these tools, the /usr/ and /etc/ hierarchies become stacks (by means of overlayfs) of read-only, cryptographically protected, individually signed file system layers.

2024-05-06 07:49:06

1️⃣0️⃣ Here's the 10th installment of posts highlighting key new features of the upcoming v256 release of systemd.
You might be aware of systemd-sysext: a component of systemd that can overlay immutable disk images (DDIs) on top of /usr/, to extend it in a secure, and again, immutable fashion. It has a companion tool systemd-confext that does the same over /etc/.

2024-05-03 12:52:46

- reply

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

2024-05-03 08:22:20

- reply

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.

2024-05-03 08:09:45

- reply

… 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.

2024-05-03 08:02:52

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, …

2024-05-02 13:11:21

- reply

@npub1raw…vcpq i pinned some of them now. But it refuses to let me pin more, hence I figure this is where it ends. Sorry.

2024-05-02 12:56:56

- reply

@npub106w…cln7 we might look into that eventually, dunno. Right now the tools are semantically too different. Thus I wouldnt want to claim drop-in compat.

2024-05-02 12:55:56

- reply

@npub154d…t24h i dont see a way to make that happen. Sorry.

2024-05-02 08:22:32

- reply

@npub18k7…l6mu yes it will. You have to provide the disk encryption key once, hence you need to log in once. From that point on it will work however.

2024-05-02 07:51:26

- reply

That's the gist of it at least. It's a bit more involved IRL.
Anyway, that's all for today, let's see if I can keep this up and post installment #9 soon.

2024-05-02 07:50:27

- reply

… then get out of the way, and let the real shell take over.
Howe does this feel from the client side? Basically if you "ssh" into a host like that, the regular SSH authentication takes place. If this succeeds there are now two options:
1. if the home dir alreads has been unlocked, you get the shell directly as on classic UNIX systems.
2. if the home dir as not been unlocked yet, you get a quick prompt to do so, and once that succeeded you get your shell.

2024-05-02 07:45:57

- reply

So, what's new regarding this problem in v256? Well, it works now: you finally can log in via SSH directly into your super secure systemd-homed account.
How did we make this happen? Roughly like this: first, we let SSH do its authentication. If that succeeded then we permit the log in to go though, but temporarily provide a slightly different user record for the user, where the login shell in the record is redirected to a small stub tool provided by systemd.

2024-05-02 07:34:18

8️⃣ Here's the 8th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
You might be aware of systemd-homed, a small service in systemd which can manage encrypted, portable home directories for you. It supports multiple storage backends, but the most relevant maintains a per-user LUKS disk image for each home directory, and ties the encryption of it to your user's authentication credentials. It supports FIDO2 and PKCS11 (in addition…

2024-05-02 07:18:09

- reply

@npub137e…h40x if it makes you feel better, we actually always check PK, regardless if the image's signing key is in the kernel keyring or not. we just use different PK action names however.

2024-05-01 15:34:47

- reply

@npub12jk…uvhg you can already run nspawn unpriv on v256, just like that -- as long as you operate with signed disk images. I.e. not with image dirs

2024-05-01 15:15:36

- reply

@npub1n88…f5ay unlike af_unix and af_vsock, af_inet is unreliable, needs encryption/authentication and so on, comes available only during late boot, typically after dhcp and so on, and hence is a very very different beast.

2024-05-01 11:49:03

- reply

@npub1tny…z6px no. systemd does not implement the policy logic after all. its polkit that does. Polkit could certainly use some tool like that.

2024-05-01 09:05:04

Seems its that season of the year again, where I get to populate my blocklists of assholes on the Internet.
Good to get a personal refresher on how the wider audience on the Internet behaves. 🤮

2024-05-01 08:14:15

- reply

@npub1ucj…rvs3 it's a reference to SO_PEERCRED, SO_PEERPIDFD, SO_PEERSEC, SO_PEERGROUPS. It's how a process can securely determine the peer of an AF_UNIX socket, by asking the kernel.

2024-05-01 07:54:37

- reply

@npub1800…nm9e I am not convinced it should be too simple to type. It's a privilege escalation mechanism after all.
Also, I like my bikesheds green.

2024-05-01 07:11:14

- reply

@npub1cpz…pp3l i have no idea what toolbox is but if that is some container tech that allows you to escape the container via sudo then I probably don't even want to know.

2024-05-01 06:05:10

- reply

Various tools (including: systemd-nspawn, systemd-dissect, RootImage= in service files) have been updated to make use of this new IPC service, and thus can now operate without privileges. Or in other words: there's now unprivileged systems-npsawn containers. Yay!)
And that's all for today. See you soon for the 8th installment of this series.

2024-05-01 06:04:54

- reply

Primarily this means: the DDI *must* come with valid dm-verity data and a signature recognized by the system's keyring (well, if this is missing a polkit authorization is attempted – the user might possibly allow this anyway, if polkit is letting them). And the client must also pass in a user namespace fd (which cannot be the system's main one) to which the mount is restricted.

2024-05-01 06:04:42

- reply

llowing unprivileged users to just arbitrarily mount file systems is hence a security issue on many levels.
With v256 we are opening this up nonetheless – within limits. Specifically, there's now a small IPC interface where clients can pass an fd to a disk image file to, and get back a mount fd they can attach to a location in the file system. To lock this down securely, a couple of requirements are enforced however.

2024-05-01 06:04:18

- reply

And that for a reason: kernel file system developers mostly do not consider attacks on the kernel through rogue file system images a security vulnerability. File systems are very complex data structures after all, and guaranteeing that a rogue fs image can't exploit the kernel (or just guarantee algorithmic boundedness) is very very hard. Moreover, file systems can carry dangerous things, such as SUID and SGID binaries, or executables with file system capabilities set.

2024-05-01 06:04:02

- reply

so that you can have the basic OS image, layers of extensions on top, and finally app images as payload – all shipped as DDIs with strongest cryptographic guarantees.
So, while systemd has been strong on DDIs already, there's one thing we did *not* provide until v256: the ability to work with DDIs from unprivileged code. Mounting file systems is after all a privileged operation on its lowest level and (with some exceptions) not accessible to unprivileged users.

2024-05-01 06:03:41

- reply

Many of systemd's tools have a --image= switch that tells them to operate on a DDI rather than directly on the file system.
In my personal view, I am pretty sure an OS (specifically: all the code and immutable vendor shipped resources) should be composed entirely from DDIs, because they bring a very high security level (i.e. every single read is validated when it is made), but are nicely composable, …

2024-05-01 06:03:17

- reply

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.

2024-05-01 06:03:00

7️⃣ Here's the 7th installment of my series of posts highlighting key new features of the upcoming v256 release of systemd.
In systemd we put a lot of focus on operating with disk images, specifically file system images that carry an expressive GPT partition table – something that we call DDIs ("Discoverable Disk Images").

2024-04-30 21:31:23

- reply

@npub1eh4…8h0k well, sockets.target only works for socket activated services, which unfortunately not everything qualifies as.

2024-04-30 16:24:48

- reply

@npub1ekn…2g2y thanks for the flowers but neither of those env vars are systemd inventions or concepts.

2024-04-30 16:22:56

- reply

@npub19re…r8k9 i am not convinced that memory safety is the big problem of sudo. Its other things. Hence deeply unimpressed.

2024-04-30 16:22:10

- reply

@npub1wx7…qmv5 we have been going forth and back on this internally, we are not going to reopen that can of worms, sorry. Its a bit bikesheddy at this point...

2024-04-30 12:11:44

- reply

@npub1pej…w9hv Just read what I originally wrote. I think I a was pretty clear.

2024-04-30 09:36:27

- reply

@npub1srf…f793 if you are in a chroot/emergency shell then you are root anyway, why bother with sudo then?

2024-04-30 08:27:22

- reply

i.e in pretty much the same way you can securely parameterize a service with them, you can also parameterize the whole system with them. Of course, it's ultimately the system's services that consume them, hence there's a propagation scheme in place: you can pass credentials into the system, and then selectively propagate these into individual services that they are supposed to be consumed in. And not just that you can actually propagate them further down the tree, …