SoylentNews is people
SoylentNews
from the resistance-is-futile.-/home-will-be-assimilated dept.
Good News:
Linux home directory management is about to undergo major change:
With systemd 245 comes systemd-homed. Along with that, Linux admins will have to change the way they manage users and users' home directories.
[...] 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.
[...] 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.
[...] 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.
[...] 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.
Older articles:
- Pack Your Bags – Systemd Is Taking You To A New Home
- Systemd-Homed Merged As A Fundamental Change To Linux Home Directories
Will systemd be considered complete once the kernel and boot loader have been absorbed into systemd?
(Score: 4, Interesting) by Thexalon on Saturday May 02 2020, @02:55PM
The thing I've also noticed about Lennart's approach is that it seems to have carefully ignored everything about *why* the old way of doing things was the old way of doing things.
A key design decision systemd made very early on that has colored everything it has done since is "text-based communication between processes is bad". And this is the exact opposite of what Thompson, Ritchie, Kernighan, et al were trying to do when they built Unix, namely to avoid giant blobs of code where you can't easily examine or modify how the various parts talk to each other. And there was a very good reason for that: Those guys had experienced lots of quite complex operating systems with giant blobs of code where they couldn't easily examine or modify how the various parts talk to each other, and found them to be inflexible and hard to work with. This decision is precisely what leads to monstrosities like binary logs that can only be read if you have the right tools on hand and were written to disk without errors (even as the system might be in the process of crashing).
A key assumption that went into the design of Unix was "anything can break in ways we didn't anticipate, so let's make sure an admin can cope and fix it". A key assumption that went into the design of systemd was "anything that breaks breaks in a way that Lennart anticipated", and that assumption is so key that when things have broken in ways Lennart didn't anticipate his response has frequently amounted to "WONTFIX - theoretically impossible, so the bug report must be wrong". As an example of this being a problem, the experience that will always color my opinion of systemd was the day I rendered my system unbootable by cold-unplugging my mouse, because apparently Lennart hadn't anticipated that somebody might do that, and rather than start up without mouse support or drop me to a single-user shell or even spit out an error message systemd instead decided to show me a black black screen with a non-responsive keyboard.
And the thing is, I've worked with people like Lennart before, folks who were completely certain that their way of doing things was the One True Way and everyone else didn't understand their vision and skill and if those nattering nabobs of negativism would just let them code the results would be great all around. And every single one of them produced code that didn't actually work very well and was a nightmare to fix.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.