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

Figure 1: LUKS storage option: When a user logs in, the systemd-homed service looks for a LUKS2 volume with a label that matches the username. The service then attempts to unlock the encrypted volume using the login password. If the process completes successfully, the home directory is mounted and the user granted access.