pid_eins

pid_eins, 20 days ago to random

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…

pid_eins, 6 months ago to random

Did you know you could control brightness of the red dot on the i of the "ThinkPad" on the top-side of your thinkpad? I sure didn't:

this turns it off:

echo 0 | sudo tee /sys/class/leds/tpacpi::lid_logo_dot/brightness

and this turns it on:

echo 255 | sudo tee /sys/class/leds/tpacpi::lid_logo_dot/brightness

I don't really know what this information is good for, but hey, isn't it awesome to have a 1px display on the outside of your laptop?

pid_eins, 7 months ago to random

This whole mess just makes me think we should try harder to kick suid/fcaps out of general purpose Linux distributions. The whole concept is fundamentally backwards, and one of the major weaknesses of traditional UNIX I am sure. The idea behind suid/fcaps of first granting the privileges, inheriting some major, uncontrolled part of the execution environment/resource context/security context and then expecting the binary to securely gate its misuse is just a major mistake: https://www.openwall.com/lists/oss-security/2023/10/03/2

pid_eins, 1 month ago to random

This is such a bad bad API compat breakage:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e81cd5a983bb35dabd38ee472cf3fea1c63e0f23

It's used all over the place in userspace. In systemd we use it:

1. to detect if a block device has partition scanning off or on
2. In our udev test suite, to validate devices are in order
3. udev rules use it for some feature checks (in older versions of systemd).

And it's even a frickin documented userspace API:

https://www.kernel.org/doc/html/v5.5/block/capability.html

So much about that nonsensical "we don't break userspace" kernel mantra.

pid_eins, 1 month ago to random

PSA: In context of the xzpocalypse we now added an example reimplementation of sd_notify() to our man page:

https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes

It's pretty comprehensive (i.e. uses it for reload notification too), but still relatively short.

In the past, I have been telling anyone who wanted to listen that if all you want is sd_notify() then don't bother linking to libsystemd, since the protocol is stable and should be considered the API, not our C wrapper around it. After all, the protocol is so trivial

pid_eins, 17 days ago to random

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…

pid_eins, 1 month ago to random

A while back we started to turn many of the library dependencies of systemd from regular ELF dependencies (which you can explore with tools like lddtree or readelf -d … | grep NEEDED) into dlopen() deps, in order to minimize the dep footprint of systemd. The primary reason for this was to make it easier to build small disk images without optional components, in particular for the purpose of initrds or container deployments. Recently, another reason for doing this came into focus:

pid_eins, 24 days ago (edited 22 days ago) to random

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…

pid_eins, 4 months ago to random

Here's a fun little thing we commited to systemd the other day: the concept of .v/ directories. What do we mean by that? Many of systemd's commands that take big resource files that are often versioned (e.g. a disk image file you could pass to sysemd-nspawn's --image= switch) now learnt a magic trick if you pass a path whose last component has the suffix ".v" and is a directory. If so, the tool will iterate through the dir's contents, do a version sort and automatically pick the newest version.

pid_eins, 13 days ago to random

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

pid_eins, 12 days ago to random

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…

pid_eins, 10 days ago to random

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

pid_eins, 6 months ago to random

Here's a little new project of mine:

https://github.com/poettering/diskomator

It's an mkosi-built OS-in-a-single-EFI-binary whose only job is to expose all local disks via NVMe-TCP. You can write it to an USB stick, or drop it in your ESP, and if you boot it, all block devices are exposed to the network. The suggested command line to connect to this disk is shown on screen.

This makes use of the systemd-storagetm service we added for systemd v255, as well as the esp output added in mkosi v19.

pid_eins, 22 days ago to random

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

You might have heard of the sd_notify() protocol that services running on systemd can use to notify the service manager about status changes, in particular about service readiness. systemd uses that to synchronize start, reload and stop operations between daemon code and service manager (as well as a multitude of other things).

pid_eins, 4 months ago to random

Here's another little feature we scheduled for the next systemd release. Everyone knows SSH well, and it's great to connect to hosts remotely, and even do file transfer. It's probably the single most relevant way to talk to some host for administration and various other tasks. It's a bit fragile though: it requires networking, and that even if we talk to a local VM or full OS container. But precisely networking is one of the things you might want to administer via SSH, hence you have a cyclic…

pid_eins, 21 days ago (edited 21 days ago) to random

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

You might be aware of systemd's per-service setting "ProtectSystem=". When used it ensures the service lives in its own mount namespace, detached from the host's and various key directories become read-only to the service, in particular /usr/. This reflects the fact there's very little code that should ever be able to to write to /usr/.

pid_eins, 19 days ago to random

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

pid_eins, 18 days ago to random

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

pid_eins, 16 days ago to random

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

pid_eins, 6 days ago (edited 6 days ago) to random

1️⃣4️⃣ Here's the 14th 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.

pid_eins, 23 days ago (edited 22 days ago) to random

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…

pid_eins, 6 months ago to random

So we merged this → https://github.com/systemd/systemd/pull/28891 into systemd today. I like to believe that this is a major step towards closing the "TPM gap" we have on Linux toward other OSes. It can automatically generate an automatic TPM2 PCR policy from various inputs covering the PCRs that generally are hard to predict by the OS vendor, i.e. things like local firmware versions, extension cards and so on. It stores this in an NV index in the TPM. Things like LUKS can then be locked against that NV index.

pid_eins, 1 month ago to random

As you might guess I get a certain amount of "fan" mail regularly. It's usually pretty dumb and not worth to mention. But sometimes it's so funny, that I just have to share the good parts of it. So here some comments from a recent mail I got (sorry, in German):

Subject: Tja, schade! War definitiv die falsche Entscheidung zu Microsoft zu wechseln

Hi Lennart!

Das war schon eine ziemliche Überraschung für uns alle!!!

…

pid_eins, 6 months ago to random

I recently implemented a fun little feature for systemd: inspired by MacOS' "target disk mode", a tiny tool called systemd-storagetm, that exposes all local block devices as NVMe-TCP devices, as they pop up. The idea is that if available in your initrd you can just boot into that (instead of into your full OS), and can access your disks via NVMe-TCP (in case you wonder what that is: it's the new hot shit for exposing block devices over the network, kinda like iSCSI, NBD, …, but cool).

pid_eins, 1 year ago to random

Now to one of the big questions of our times: what's better style? open("…", O_DIRECTORY|O_RDONLY|O_CLOEXEC) or open("…", O_DIRECTORY|O_CLOEXEC)?

Of course, both are entirely equivalent, because O_RDONLY on Linux is 0. But on a philosophical, conceptual level, what's the better way to write this?

(Asking because half of the systemd codebase does it one way, the other does it the other way.)

This is your time to shine, and contribute to the major philosophical discussion of today!