That’s systemd for you.

From The Collaborative International Dictionary of English v.0.48 [gcide]:

  boondoggle \boon"dog*gle\ v.
    [...]
     2. a useless, wasteful, or impractical project; -- especially
        one authorized by a government agency as a favor to
        partisans, to employ unemployed people, or in return for
        corrupt payments.
        [PJC]

Today’s new word :)

Maybe UID/GID namespaces could be utilized instead? One on-disk ID, preferably random-ish, one synthesized per system.

That smells of WNT though.

Just listing all the files and piping to wc -l took 6 minutes

Did you do that >/dev/null? Otherwise, the bottleneck was probably your terminal emulator :)

But yeah, if we’re talking single mount per home dir, I think the UID should be a mount option.

For me, systemd is actually the reason why I cannot stand Free/OpenBSD anymore. I don’t want to see another shell script for controlling important system software that might or might not work. Perhaps one of these days, OpenBSD pulls a typical OpenBSD move and some cool hacker reimplements the best parts of systemd (mostly the service administration really) into a single cohesive package.

What do you use now? What are the tradeoffs you had to make?

[Comment removed by author]

You have to put everything you need for decryption in an unencrypted place like a tmpfs before you destroy the keys on suspend:

https://lonkamikaze.github.io/2014/04/01/geli-suspend-resume-with-full-disk-encryption

(tbh, just opening a process that wouldn’t need to load from the encrypted disk sounds enough, all this tmpfs stuff is because that one was done with shell hackery instead of building a specialized application)

Since this is only used for your home directory, and not your entire system, there really shouldn’t be any chicken-egg problem here. If your system partition is also encrypted, then its key can’t be clear from memory when you suspend (without tomfoolery with tmpfs), but as long as it’s just your home folder, all you need to do is make sure that you can prompt the user for their password without reading from their home folder.

Considering that systemd already puts a user’s entire login session in a process control group and a mount namespace for user-segregated /tmp folders, it doesn’t even seem that hard. Just freeze the cgroup, unmount the home volume, suspend, and on resume prompt the user for their password, decrypt their home folder again, unfreeze the cgroup, and your back online.

I’d assume their use case is a USB stick, with a built-in yubikey for authentication. It’d handle all the authentication and also provided a physical 2FA. I don’t know how I’d feel about employees all carrying them around town. There’s still a threat of malware getting on the USB in that case.

Most of the systems I access, I don’t have physical access to, so “Home directory on a USB stick” doesn’t work.

I too struggle with the whole “portable” usb based home directory, but I can see a big use case for obviating UIDs away from the user’s concern and reworking NSS and all the other old style libc stuff for getting user based information and authentication.

Problem with USB sticks with that setup is that they really are meant as “save file here time to time” kind of device. Using them like hard disk wears them down unbelievably quickly and they tend to have only one failure mode: catastrophic failure. (I am working on a project where we do exactly this and we found it out hard way)

Yeah, why not