Reinventing Linux home directories with systemd-homed
New Kid
Systemd has already changed almost everything about the Linux startup process. Now an experimental new feature takes on the challenge of user home directories.
Systemd [1] was originally released on March 30, 2010 as a replacement for System V (SvsV) and BSD init. SysV init had been part of Linux for many years. The name System V, in fact, invokes memories of an early version of the Unix operating system that predated the Linux era.
The init system is the first service that starts after the system boot, and it is responsible for starting all the other services. The term "init" is short for "initialize," and the role of the init system is to start everything that needs to be started when the OS springs to life.
SysV init was stable and predictable, but many developers believed it was past its prime. Perhaps the biggest issue with SysV init was that it was designed before the age of multiprocessing systems and could only do one thing at a time. Processes and services started in serial fashion, which significantly slowed down the boot process. Other developers and users wished for a system that was more consistent, with a better API and a more sophisticated means for expressing dependencies.
A number of alternatives to SysV init emerged and were the subject of lively debates on Linux blogs and news lists. SysV also had its supporters. Many Linux developers didn't see sufficient reason to change it, since it had been working well for so long. Others believed the complex frameworks offered as replacements were a violation of the core Unix design preference for simplicity and single-purpose tools.
A massive debate played out in the Linux space, and in the end, all the major Linux distros adopted systemd. A few holdouts remain (Devuan, for instance, is a fork of the Debian project that still used SysV), but now that we have reached 2020, it is clear that systemd is here to stay.
Systemd provides a uniform method for addressing the various system daemons and utilities, as well as device management, user login, network connections, and event logging. Prior to systemd, these tasks were handled by a collection of single-purpose tools. So when you needed to configure various pieces of the initialization process, you'd have to touch each one of those systems individually.
Lennart Poettering and Kay Sievers, both software engineers for Red Hat, developed systemd with the goal of creating a single system to control initialization that would express dependencies, allow more concurrent or parallel processes during boot time, and reduce computational overhead within the shell. But Poettering said from the beginning that systemd would be "never finished, never complete." The systemd environment already includes such features as:
- Daemon initialization
- Snapshot support
- Process tracking
- Inhibitor locks
But Poettering wasn't content. Another important part of the system startup that was due for an upgrade was user home directories. With the new systemd-homed service that will appear in systemd 245 [2], the developers will address an aspect of the Linux startup process that many experts say should have been changed a long time ago.
No Place Like Home
The Linux home directory is a crucial part of the system directory hierarchy. Residing in the /home
directory are user files, user data, and configuration settings. To date, many Linux users and admins have placed /home
on a partition that is separate from the operating system so that, should something go wrong with the operating system, the data will still be safe. However, because of the way /home
is handled within the operating system, system-to-system /home
migration is never quite as easy as it should be.
In a conventional Linux environment, user information (such as username, ID, full name, home directory, and shell) are stored in /etc/passwd
. Any user on the system can view that file. The password associated with users is stored in /etc/shadow
. Unlike /etc/passwd
, /etc/shadow
cannot be viewed by just anyone. During login, the system authenticates the password with /etc/shadow
and, upon successful authentication, reads /etc/passwd
for the location of the user's home directory. For the simple act of logging in, three pieces are required for success, and two of those pieces reside with the system files – outside of the /home
directory.
With systemd-homed, the systemd developers eliminate this dependency on external files, thus allowing home directories to become truly portable. The new approach places all information (username, group membership, password hashes) in a cryptographically signed, user-specific record within a single JSON file. This file is flexible, so it can handle just about any type of user information.
Portable Home
Eliminating the dependency on the system-based /passwd
and /etc/shadow
files means you will be able to take your home directory and move it to another drive (even a flash drive) and work with your data and configurations from within any systemd-homed-enabled Linux distribution.
Imagine being able to copy your home directory (and every associated configuration file) to a USB flash drive and have everything work as if it were still happily connected to your home computer – not just the user files, but the entire environment, including personal settings, preferences, and even authentication information. This new system could lead to completely self-contained users that can easily be migrated from system to system. In fact, you could plug in that flash drive and the user will (upon being granted permission by an admin user) automatically exist on the system.
How It Works
The ~/.identity
subfolder of the user's home directory contains a JSON-formatted user record that is used to confirm the user's identity. The details of the process depend on the storage mechanism. Systemd-homed supports a number of different mechanisms for storing and accessing the user home directory, including:
- Plain directory/Btrfs subvolume
- fscrypt home directories
- CIFS home directories
- LUKS home directories
According to the developers, the LUKS option is "…the most advanced and most secure storage mechanism." In the LUKS scenario, an encrypted LUKS2 volume is stored either on removable media or in a loopback file. A GPT partition table within the storage media or loopback file points to the enclosed LUKS volume. The label for the LUKS2 volume must be the same as the username. The LUKS volume contains an ext4, Btrfs, or XFS filesystem with a single directory named for the user. This directory becomes the user home directory. The ./identity
subfolder within the home directory has a copy of the user record that matches the copy stored within the LUKS header.
The user's login password is also the password used to unlock the LUKS2 volume. When the user successfully logs in, systemd-homed uses the password provided with the login to unlock the LUKS volume. The user record stored within the header is then compared to the record stored in the ./identity
folder to ensure the data has not been tampered with. If the records match and are signed with a recognizable key, the home directory is then mounted and accessible to the user (Figure 1).
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Latest Cinnamon Desktop Releases with a Bold New Look
Just in time for the holidays, the developer of the Cinnamon desktop has shipped a new release to help spice up your eggnog with new features and a new look.
-
Armbian 24.11 Released with Expanded Hardware Support
If you've been waiting for Armbian to support OrangePi 5 Max and Radxa ROCK 5B+, the wait is over.
-
SUSE Renames Several Products for Better Name Recognition
SUSE has been a very powerful player in the European market, but it knows it must branch out to gain serious traction. Will a name change do the trick?
-
ESET Discovers New Linux Malware
WolfsBane is an all-in-one malware that has hit the Linux operating system and includes a dropper, a launcher, and a backdoor.
-
New Linux Kernel Patch Allows Forcing a CPU Mitigation
Even when CPU mitigations can consume precious CPU cycles, it might not be a bad idea to allow users to enable them, even if your machine isn't vulnerable.
-
Red Hat Enterprise Linux 9.5 Released
Notify your friends, loved ones, and colleagues that the latest version of RHEL is available with plenty of enhancements.
-
Linux Sees Massive Performance Increase from a Single Line of Code
With one line of code, Intel was able to increase the performance of the Linux kernel by 4,000 percent.
-
Fedora KDE Approved as an Official Spin
If you prefer the Plasma desktop environment and the Fedora distribution, you're in luck because there's now an official spin that is listed on the same level as the Fedora Workstation edition.
-
New Steam Client Ups the Ante for Linux
The latest release from Steam has some pretty cool tricks up its sleeve.
-
Gnome OS Transitioning Toward a General-Purpose Distro
If you're looking for the perfectly vanilla take on the Gnome desktop, Gnome OS might be for you.