When systemd was released in 2010, there was a storm of vitriol surrounding the change in how services were to be started in Linux. The new mechanism was touted as being bloated and far too complicated to be useful. Since then, all enterprise Linux distributions have adopted systemd and the majority of desktop distributions have as well. 

For those who aren’t familiar with systemd, it is that which initializes all systems on the Linux platform. Anyone that manages Linux within a data center should be intimately familiar with this system. By providing all of the necessary controls and daemons for device management, user login, network connections, and event logging, systemd makes for easy resource initialization and management—all from a single point of entry (systemctl). 

Prior to systemd every system and resource was managed by its own tool, which was clumsy and inefficient. Now? Controlling and managing systems on Linux is incredibly easy. 

But one of the creators, Leannart Poettering, has always considered systemd to be incomplete. With the upcoming release of systemd 245, Poettering will take his system one step closer to completion. That step is by way of homed.

SEE: Implementing DevOps: A guide for IT pros (free PDF) (TechRepublic)

What is homed?

Before we dig into homed, let’s take a look at the /home directory. This is a crucial directory in the Linux filesystem hierarchy, as it contains all user data and configurations. For some admins, this directory is so important, it is often placed on a separate partition or drive than the operating system. By doing this, user data is safe, even if the operating system were to implode.

However, the way /home is handled within the operating system makes migrating the /home directory not nearly as easy as it should be. Why? With the current iteration of systemd, user information (such as ID, full name, home directory, and shell) is stored in /etc/passwd and the password associated with that user is stored in /etc/shadow. The /etc/passwd file can be viewed by anyone, whereas /etc/shadow can only be viewed by those with admin or sudo privileges.

How the /etc/passwd and /etc/shadow files work is simple:

• During the login process, the system authenticates the login attempt against /etc/shadow.

• If login is successful, the system reads the /etc/passwd entry for the user to locate the user’s home directory.

So, for the simple act of logging in, three mechanisms are required (systemd, /etc/shadow, /etc/passwd). This is inefficient, and Poettering has decided to make a drastic change. That change is homed. With homed, all information will be placed in a cryptographically signed JSON record for each user. That record will contain all user information such as username, group membership, and password hashes. 

Each user home directory will be linked as LUKS-encrypted containers, with the encryption directly coupled to user login. Once systemd-homed detects a user has logged in, the associated home directory is decrypted. Once that user logs out, the home directory is automatically encrypted.

A truly portable home directory

Outside of including a much-improved security, systemd-homed will finally enable a truly portable home directory. Because the /home directory will no longer depend on the trifecta of systemd, /etc/passwd, and /etc/shadow, users and admins will then be able to easily migrate directories within /home. Imagine being able to move your /home/USER (where USER is your username) directory to a portable flash drive and use it on any system that works with systemd-homed. You could easily transport your /home/USER directory between home and work, or between systems within your company. 

This will not just apply to user files, but with personal settings, preferences, and even authentication information.

This works by making use of the JSON user record to confirm user identity. How specifically this works will depend upon the mechanism used for storing/accessing user home directories. Such mechanisms include:

• BTRFS

• fscrypt

• CIFS

• LUKS

According to Poettering, LUKS is the most advanced and secure of the systems. With LUKS, an encrypted volume is stored on either a removable device or within a loopback file. The LUKS volume contains a single directory, named after the user, which becomes the user’s home directory and contains a copy of the user record stored within the LUKS header. 

When the user successfully authenticates, systemd-homed unlocks the LUKS volume and compares the record stored within the LUKS header to that stored in the ./identity folder. If the records and encryption keys match, the directory is mounted and accessible to the user.

How to create systemd-homed users

Unlike the current process of creating users (either with the useradd or adduser commands), systemd-homed will rely on it’s own process of creating users. Fortunately, that process won’t be terribly complicated.

In fact, like many subsystems associated with systemd, systemd-homed will have it’s own control command:

homectl

So to create a new user, the command will look something like:

sudo homectl create USERNAME --real-name="REAL NAME" --disk-size=5GB

Where USERNAME is the username and REAL NAME is the user’s first and last name.

With the homectl command, you can also:

• Activate one or more home directories

• Change the passwords on a specific home directory/user account

• Resize the amount of disk space assigned to a home directory

• Temporarily lock a home directory

• List all home directories

The caveat

Of course, such a major change doesn’t come without its share of caveats. In the case of systemd-homed, that caveat comes by way of SSH. If a systemd-homed home directory is encrypted until a user successfully logs in, how will users be able to log in to a remote machine with SSH? 

The big problem with that is the .ssh directory (where SSH stores known_hosts and authorized_keys) would be inaccessible while the user’s home directory is encrypted. Of course Poettering knows of this shortcoming. To date, all of the work done with systemd-homed has been with the standard authentication process. You can be sure that Poettering will come up with a solution that takes SSH into consideration. 

Should Poettering not be able to develop a solution for the SSH conundrum, systemd-homed will have to be relegated to desktops and laptop distributions, leaving servers out of the mix. I cannot imagine that will fly with the systemd team.

When will systemd 245 be released

At the moment, systemd 245 is still in RC2 status. You can download the source from the systemd GitHub page, but know the installation is probably far more involved than you’d want to bother with. The good news, however, is that systemd 245 should be released sometime this year (2020). When that happens, prepare to change the way you manage users and their home directories. 

Open Source Weekly Newsletter

You don’t want to miss our tips, tutorials, and commentary on the Linux OS and open source applications. Delivered Tuesdays

Sign up today

Also see