systemd-homed

systemd-homed - Home Directory / User Account Manager


systemd-homed is a system service that may be used to create, remove, change or inspect home directories.

Most of systemd-homed's functionality is accessible through the homectl(1) command.

See the Home Directories documentation for details about the format and design of home directories managed by systemd-homed.service.

Each home directory managed by systemd-homed.service synthesizes a local user and group. These are made available to the system using the User/Group Record Lookup API via Varlink, and thus may be browsed with userdbctl(1).


New in systemd245

Release notes systemd/NEWS

Lennart Poettering @ All System Go! 2019 - Reinventing Home Directories

Slides: homed-asg2019.pdf


Problems

  • needs writable /etc/ + mixed state & configuration

  • UID assignments need to be propagated between systems

  • No encryption (or mismatching encryption)

  • No modern authentication mechanisms

  • Not extensible; plenty of sidecar databases (/etc/shadow, accounts-daemon, samba, ssh, pam_limits)

  • No resource management


Personal thoughts on systemd-homed

systemd-homed is reinventing the wheels

- to solve legacy problems & adopt modern encryption + authentication

- which most people are used to

- don't even consider them `problems`


However, from time to time Linux users feel confused and question why?

userdb in home and /etc, mixing state and configurations, plenty of sidecar databases in addition to NSS user records live inside /etc - WTF


Key Concepts

Concept A

- JSON user records

- Superset of NSS records (struct passwd + struct group)

- Query via Varlink API (IPC)

- convertible forth and back

Concept B

- LUKS encrypted Home directory in loopback files

- /home/foobar.home with JSON records in ~/.identity

- managed by systemd-homed.service

A may be used without B.

Design goals

- migratable Home directories

- self-contained Home directories (i.e. mere existence of a file /home/foobar.home synthesizes a user foobar

- UID assignments as local artifact (chown() on login)

- Unification of user password and encryption key

- extensible (NSS) user records

- lock LUKS on suspend

- Yubiky (FIDO U2F) - 1st class citizen


Real World Use cases

The design goal is to solve the following problems running Linux on laptop or workstation

    1. Secure / Encrypted Home (sweet)

    2. systemctl suspend - suspend to Memory

    3. LUKS decryption key is in memory, if CIA / FBI / NSA seize the device, technically they are capable of dumping the decryption key from memory and therefore decrypt all data on the disk.

    4. fully self-contained, migratable home directory (that can live on a USB stick)

    5. No more /etc NSS user / group and sidecar databases.

    6. Yubikey (FIDO U2F)

NOTE: It is for Linux as workstation (laptop, desktop), NOT for server use cases.

Why LUKS?

Loopback File -> GPT Partition Table -> LUKS Volume with embedded Identity -> ext4/xfs/btrfs File System -> Subdirectory -> .identity

All labels: user name

(Yes, you can just use simple tools to access these home directories)

Activation

Superficial Validation -> LUKS Volume Activation/Identity Validation -> fsck -> chown -> mount -> 2nd Identity Validation


systemd 250 improvements

  • systemd-homed now defaults to btrfs zstd compression for home areas. This is inspired by Fedora’s recent decision to switch to zstd by default.

  • UID mapped mounts for home areas makes migrating home between different systems cheaper because recursive chown()ing file system trees is no longer necessary.

  • systemd-homed will now drop the kernel buffer cache once a user has fully logged out, configurable via the new --drop-caches= homectl switch


NOTE: In v250 systemd-homed started making use of UID mapped mounts for the home areas if the kernel and used file system support it. Files are now internally owned by the "nobody" user (i.e. the user typically used for indicating "this ownership is not mapped"), and dynamically mapped to the UID used locally on the system via the UID mapping mount logic of recent kernels. In the current implementation systemd-homed only maps a limited number of UIDs and GIDs making it impossible to run unprivileged containers that want to map a full POSIX compliant UID and GID range with their rootfs located within the systemd-homed managed home area. This will be fixed in subsequent releases, see https://github.com/systemd/systemd/pull/22239.


RTFM

User Record

Home

  • https://systemd.io/HOME_DIRECTORY