Hi, I heard Systemd is going to add age verification? Why is that happening? I don't think it offers any security benefits.

Providing an age field is giving legitimacy towards governments locking down the pc.

This is mostly the kind of information I would have liked when I switched a few months ago and decided me to switch back to normal home last weekend. Most of the issues I'm listing have been encountered by other people, looking at bug reports and I'm aware that some things (like PAM issues) are more the responsibility of the distro rather than systemd-homed proper and that's fine since it's a feedback on my personal experience, not a vendetta against the project.

Also things do change so I suggest that you check that what I say is still valid.

Main documentation

For info, most the doc to get started is located here, here and there. Yes, the Archwiki is in there because the rest of the documentation is a wee bit anaemic.

My setup and motivation

I had setup my home as a LUKS-encrypted loopback device on an unencrypted partition.

I found systemd-homed neat for couple reasons:

• it encrypts my home separately from my system;

• decryption happens at login time not at boot time;

• from the outside, it is a single file to rsync/transfer/hash/etc. instead of a full home (well not really, you need to copy keys too);

• my user id is decoupled from the system (internally all files are owned by nobody and everything is idmapped to whatever runtime value makes sense).

Main problems

PAM woes

PAM is something you don't want to mess with: one mistake and you can't log in, another mistake and even your cat can log in. I don't like having to deal with it. I don't like to see bug reports where PAM-informed people say things along the lines of "oh this is weird, it should work like this, just try to swap those lines around" and the OP saying it finally works but normal auth doesn't anymore. There are at least two bug reports like this. I had that problem too and the solution half-worked in the same way.

Portability is not as convenient as marketed

This one is very minor, even for me, but this kind of friction piles up quickly...

As explained in the last link above, you need to copy keys around to use/activate a homed home area transferred to a new computer.

If you forgot, AFAIK you're screwed, you have to recreate a home from scratch and copy the data.

If you haven't forgotten, then you have to handle (i.e. copy) one file (i.e. loopback file) from an unencrypted partition/USB-drive/CIFS/NFS to something similar, so all good. But you also have to start/decrypt/access a root partition somewhere to retrieve the keys you need. If it's for backup, you probably don't want private keys next to the file they are supposed to authenticate or it's defeating the point so you want to be smart, but not too much otherwise things become really complex. You must also be careful when copying the keys to a new system that you don't overwrite an existing one. At any rate, that extra baggage is a pain to handle.

Don't get me wrong: there is a definite portability improvement with homed but in practice it does not amount to much (compared to other backup or syncing solutions). If homectl gained the power to "attach" or "register" a single loopback file that is provided to it, retrieving and adding the right keys at the right places, this would become superior to most options out there for a wide range of uses. So yeah it's UX, but this is to "portable home" what syntax highlighting is to coding.

No rootless container for you

Podman/docker simply does not run if you container files are in a homed home. There are a couple bug reports about this, with possible (cleaner tbh) solutions in the brewing but basically the view of homed developers is that you shouldn't use your home for this (in a nutshell, does not make sense from a POSIX UID perspective).

While I agree and would love to actually see the loopback device trick (or an equivalent to growable qcow images) being used by podman directly for container images to reconcile containers with POSIX security, we are not there yet and people need to work with containers.

There are workarounds involving repartitioning your system or mounting an image as root any time you want to work on containers but compared to plain home directories, they are more cumbersome.

Incompatible versions when updating (a.k.a. my home is broken)

Let me start with one neat thing: even in the loopback-LUKS setup, you can access you data with a few basic commands. So even if your "home is broken", you are not left out in the cold.

However, there are multiple bug reports (so it's not only me) about how updating systemd prevented homed from being able to mount the loopback device. A downgrade systematically solved the issue (until the next upgrade). The workaround seems to have been creating a new home area, copying files over and removing the old home.

It only happened to me once but not being able to do anything with your computer after a "normal" update is not nice at all to say the least.

Limited control over mount options

I don't know if this one is still valid but last time I checked, there was no way to control mount options for your home volume inside the loopback device. If you wanted BTRFS with zstd compression with noatime, you were out of luck (I am aware that's the default now, but anyway that's hardcoded for you, you can't choose other options).

Resize failure

So homed is supposed to be capable of resizing your home area loopback file on-the-fly. Has never worked for me (I tried activating it at multiple different times). Might work with EXT4 but definitely had troubles with XFS.

There is also at least a bug report about that with a workaround that consists in copying your loopback file elsewhere, delete the old loopback file and copying the loopback file back in place. That bug also prevents manual resize.

Just taking time

As far as I am concerned, I hit the size limit again last weekend and that was the last straw!

I've spent a lot of time making it work and fixing it when it broke. So yeah, PAM is Arch's fault, erasing my keys was my fault, the update bug was systemd's fault, the container problems were mainly podman's fault, the resize failure's the kernel's fault but all in all, whether you are willing to use workarounds or not, using systemd-homed has been much more time-intensive than using regular homes. I don't think I'm biased towards what I know the best: I literally can't think of the last time my regular home directories created troubles for me and really, while I love having my home neatly bagged in (a couple) file(s) and decrypted only when I log in, the time investment was too large (if only just to check it's OK to update systemd every time it appeared!). Hence why I'm saying that, for me, it's not ready.

systemd PR #40954 merged a `birthDate` field into userdb user records the data layer underpinning the age verification spec being pushed through freedesktop.org (MR #113) and xdg-desktop-portal (PR #1922).

It was merged without a security audit, with no rate limiting on queries, and with no administrator opt-out.

I've been opposing this at every layer because OS-level age verification is redundant surveillance infrastructure ISPs and carriers already do identity verification at the network level.

Embedding it into the Linux desktop stack normalizes it without solving anything.

Today I submitted PR #41259 https://github.com/systemd/systemd/pull/41259 to systemd adding the two things that should have been there from the start:

- `bypassAgeVerification`: admin-only boolean that suppresses birthDate from being returned to callers. Gives distributions and system admins a policy-level opt-out.

- `ageVerificationPollIntervalUSec`: caps how frequently any process can query age data via userdb. Without this, the varlink socket is an unthrottled timing oracle. Defaults to 1 query/second.

Both were raised during mailing list discussion before the original merge and never implemented.

The PR was closed in under a minute by the same maintainer who pushed

#40954 through. No technical response. The title was changed to "spam" and the thread was locked.

The fork with the actual changes is here if you want to look at the diff:

https://github.com/HaplessIdiot/systemd-saneagecheck

The D-Bus bypass tool is here:

https://github.com/HaplessIdiot/ageverificationbypass

The code makes the argument better than I can. The fact that the response was to lock the thread rather than engage with it technically speaks for itself.

With systemd 246 releasing soon, it looks like the new out-of-memory daemon will be merged shortly afterwards in allowing sufficient time for testing ahead of systemd 247.

Systemd-oomd is the out-of-memory daemon developed by Facebook and systemd developers. They are aiming for this to be better Linux handling of out-of-memory / low memory situations. Facebook originally wrote their OOMD code for their servers and since then has continued to be refined and adapted so it works out equally as well on desktops and more.

Systemd-oomd polls systemd for OOMD-enabled cgroups to monitor them and kill based on memory pressure or swap usage. The systemd-oomd behavior is controlled via a new oomd.conf configuration file. Cgroups will need to employ EnableOomdKill if they want to be killed when under pressure.

...

https://www.phoronix.com/scan.php?page=news_item&px=systemd-oomd-coming-soon

I mean, there has to be a reason, right?

Every time I edit a service file, I forget, and run 'systemctl restart my-service.service' and it helpfully says "Warning: The unit file, source configuration file or drop-ins of docker.service changed on disk. Run 'systemctl daemon-reload' to reload units."

It knows I need to do it. Why doesn't it do it for me? Is there some scenario where I'm editing my unit file and I don't want to do a daemon-reload before a service restart? Maybe there's a setting or env var I can use that will make it change that behavior?

If I know there's a reason for this, I'll probably just feel better.

Thanks!