Home directories have been a fundamental part on any Unixy system since day one. They’re such a basic element, we usually don’t give them much thought. And why would we? From a low level point of view, whatever location $HOME is pointing to, is a directory just like any other of the countless ones you will find on the system — apart from maybe being located on its own disk partition. Home directories are so unspectacular in their nature, it wouldn’t usually cross anyone’s mind to even consider to change anything about them. And then there’s Lennart Poettering.
In case you’re not familiar with the name, he is the main developer behind the systemd init system, which has nowadays been adopted by the majority of Linux distributions as replacement for its oldschool, Unix-style init-system predecessors, essentially changing everything we knew about the system boot process. Not only did this change personally insult every single Perl-loving, Ken-Thompson-action-figure-owning grey beard, it engendered contempt towards systemd and Lennart himself that approaches Nickelback level. At this point, it probably doesn’t matter anymore what he does next, haters gonna hate. So who better than him to disrupt everything we know about home directories? Where you _live_?
Although, home directories are just one part of the equation that his latest creation — the systemd-homed project — is going to make people hate him even more tackle. The big picture is really more about the whole concept of user management as we know it, which sounds bold and scary, but which in its current state is also a lot more flawed than we might realize. So let’s have a look at what it’s all about, the motivation behind homed, the problems it’s going to both solve and raise, and how it’s maybe time to leave some outdated philosophies behind us.
A Quick Introduction To Systemd
homed part of the endeavor, let’s bring everyone on the same page about systemd itself. In simple words, systemd handles everything that lies beyond the kernel’s tasks to start up the system: setting up the user space and providing everything required to get all system processes and daemons running, and managing those processes along the way. It’s both replacing the old init process running with PID 1, and providing an administrative layer between the kernel and user space, and as such, is coming with a whole suite of additional tools and components to achieve all that: system logger, login handling, network management, IPC for communication between each part, and so on. So, what was once handled by all sorts of single-purpose tools has since become part of systemd itself, which is one source of resentment from people latching on to the “one tool, one job” philosophy.
Technically, each tool and component in systemd is still shipped as its own executable, but due to interdependency of these components they’re not really that standalone, and it’s really more just a logical separation. systemd-homed is therefore one additional such component, aimed to handle the user management and the home directories of those users, tightly integrated into the systemd infrastructure and all the additional services it provides.
But why change it at all? Well, let’s have a look at the current way users and home directories are handled in Linux, and how systemd-homed is planning to change that.
The Status Quo Of $HOME And User Management
Since the beginning of time, users have been stored in the /etc/passwd file, which includes among other things the username, a system-unique user id, and the home directory location. Traditionally, the user’s password was also stored in hashed form in that file — and it might still be the case on some, for example embedded systems — but was eventually moved to a separate /etc/shadow file, with more restricted file permissions. So, after successfully logging in to the system with the password found in the shadow file, the user starts off in whichever location the home directory entry in /etc/passwd is pointing to.
In other words, for the most fundamental process of logging in to a system, three individual parts that are completely independent and separated from each other are required. Thanks to well-defined rules that stem from simpler times and have since remained mostly untouched, and which every system and tool involved in the process commendably abides by, this has worked out just fine. But if we think about it: is this really the best possible approach?
Note that this is just the most basic local user login. Throw in some network authentication, additional user-based resource management, or disk encryption, and you will notice that /etc/passwd isn’t the place for any of that. And well, why would it be — one tool, one job, right? As a result, instead of configuring everything possibly related to a user in one centralized user management system that is flexible enough for any present and future considerations, we just stack dozens of random configurations on top of and next to each other, with each one of them doing their own little thing. And we are somehow perfectly fine and content with that.
Yet, if you had to design a similar system today from scratch, would you really opt for the same concept? Would your system architect, your teacher, or even you yourself really be fine with duplicate database entries (usernames both in passwd and shadow file), unenforced relationships (home directory entry and home directory itself), and just random additional data without rhyme or reason: resource management, PAM, network authentication, and so on? Well, as you may have guessed by now, Lennart Poettering isn’t much a fan of that, and with systemd-homed he is aiming to unite all the separate configuration entities around user management into one centralized system, flexible enough to handle everything the future might require.
Knock Knock – It’s Systemd
So instead of each component having its own configuration for all users, systemd-homed is going to collect all the configuration data of each component based on the user itself, and store it in a user-specific record in form of a JSON file. The file will include all the obvious information such as username, group membership, and password hashes, but also any user-dependent system configurations and resource management information, and essentially really just anything relevant. Being JSON, it can virtually contain whatever you want to put there, meaning it is easily extendable whenever new features and capabilities are required. No need to wonder anymore which of those three dozen files you need to touch if you want to change something.
In addition to user and user-based system management, the home directory itself will be linked to it as a LUKS encrypted container — and this is where the interesting part comes, even if you don’t see a need for a unified configuration place: the encryption is directly coupled to the user login itself, meaning not only is the disk automatically decrypted once the user logs in, it is equally automatic encrypted again as soon as the user logs out, locks the screen, or suspends the device. In other words, your data is inaccessible and secure whenever you’re not logged in, while the operating system can continue to operate independently from that.
There is, of course, one downside to that.
Chicken / Egg Problem With SSH
If the home directory requires an actively logged-in user to decrypt the home directory, there’s going to be a problem with remote logins via SSH that depend on the SSH decryption key found inside the (at that point encrypted) home directory. For that reason, SSH simply won’t work without a logged in local user, which of course defies the whole point of remote access.
That being said, it’s worth noting that at this stage, systemd-homed is focusing mostly on regular, real human users on a desktop or laptop, and not so much system or service-specific users, or anything running remotely on a server. That sounds of course like a bad excuse, but keep also in mind that systemd-homed will change the very core of user handling, so it’s probably safe to assume that future iterations will diminish that separation and things will work properly for either type of user. I mean, no point to reinvent the wheel if you need to keep the old one around as well — but feel free to call me naive here.
Ideally, the SSH keys would be migrated to the common-place user management record, but that would require some work on SSH’s side. This isn’t happening right now, but then again, systemd-homed itself is also just a semi-implemented idea in a git branch at this point. It’s unlikely going to be widely adapted and forced onto you by the evil Linux distributions until this issue in particular is solved — but again, maybe I’m just overly optimistically naive.
Self-Contained Users With Portable Homes
But with user management and home directory handling in a single place and coupled together, you can start to dream of additional possible features. For instance, portable home directories that double as self-contained users. What that means is that you could keep the home directory for example on a USB stick or external disk, and seamlessly move it between, say, your workstation at home and your laptop whenever you’re on the move. No need to duplicate or otherwise sync your data, it’s all in one place with you. This brings security and portability benefits.
But that’s not all. It wouldn’t have to be your own device you can attach your home directory to, it could be a friend’s device or the presenter laptop at a conference or really any compatible device. As soon as you plug in your home directory into it, your whole user will automatically exist on that device as well. Well, sort of automatically. Obviously, no one would want some random people roaming around on their system, so the system owner / superuser will still have to grant you access to their system first, with a user and resource configuration based on their own terms, and signed to avoid tempering.
Admittedly, for some of you, this might all sound less like amazing new features and more like a security nightmare and mayhem just waiting to happen. And it most certainly will bring a massive change to yet another core element of Linux where a lot could possibly go wrong. How it will all play out in reality remains to be seen. Clearly it won’t happen over night, and it won’t happen out of nowhere either — the changes are just too deep and fundamental. But being part of systemd itself, and seeing its influence on Linux, one has to entertain the idea that this might happen one day in the not too distant future. And maybe it should.
Times Are Changing
Yes, this will disrupt everything we know about user management. And yes, it goes against everything Unix stands for. But it also gets rid of an ancient concept that goes against everything the software engineering world has painfully learned as best practices over all these decades since. After all, it’s neither the 70s nor the 80s anymore. We don’t have wildly heterogeneous environments anymore where we need to find the least capable common denominator for each and every system anymore. Linux is the dominant, and arguably the only really relevant open source “Unix” system nowadays — even Netflix and WhatsApp running FreeBSD is really more anecdotal in comparison. So why should Linux really care about compatibility with “niche” operating systems that are in the end anyway going to do their own thing? And for that matter, why should we still care about Unix altogether?
It generally begs the question, why do we keep on insisting that computer science as a discipline has reached its philosophical peak in a time the majority of its current practitioners weren’t even born yet? Why are we so frantically holding on to a philosophy that was established decades before the world of today with its ubiquitous internet, mobile connectivity, cloud computing, Infrastructure/Platform/Software/Whatnot-as-a-Service, and everything on top and below that has become reality? Are we really that nostalgic about the dark ages?
I’m not saying that the complexity we have reached with technology is necessarily an outcome we should have all hoped for, but it is where we are today. And it’s only going to get worse. The sooner we accept that and move on from here, and maybe adjust our ancient philosophies along the way, the higher the chance that we will actually manage to tame this development and keep control over it.
Yes, change is a horrible, scary, and awful thing if it’s brought upon us by anyone else but ourselves. But it’s also inevitable, and systemd-homed might just be the proverbial broken egg that will give us a delicious omelette here. Time will tell.
“… the encryption is directly coupled to the user login itself, meaning not only is the disk automatically decrypted once the user logs in, it is equally automatic encrypted again as soon as the user logs out, locks the screen, or suspends the device.”
What? How is this a good thing?
So I have to transcode multiple large video files. The files are in my $HOME, as you would expect. I start the process, assume it’s going to take a long time to complete (e.g. >20 hours), and decide to walk away and come back to it later. So when I lock my screen, the job crashes because it’s files just got encrypted? So to complete the task, I would in theory have to sit at my desk for the entire process? Thanks for that!
SystemD should just be referred to as it’s own operating system by now. It’s removed and overtaken enough of unix/linux that there is hardly any similarity anymore.
As someone who creates embedded Linux systems for a day job, systemd has made my life so much easier. And it has made ordering the start up sequence with custom steps needed by customers so very easy. systemd is taking over because it is better. If it was not then it would not have taken of the ground. I’ve been working with these systems way before the RPi was even an idea. back then it was a nightmare trying to workout how the kernel and the system supplied by the manufacture was put together let alone customise it. systemd for the win. Mind you I’m a developer and not a wannabe trying to look like a developer by just repeating the same old crap from stack exchange.
Yes I am a dinosaur, nevertheless you don’t think they are changing too much? Why just call it anything else? Removing Vi, Perl, on some systems nowadays I need to discover how to edit a file… How to search and replace over a folder…. That basic things…
I am not homesick kind of person, and at the end will be using both systems anyway. We lived with System V variants and BSD’s inits to see the change coming. Please keep the roots or jump into a new car
Simply NO to “C:\systemd” on my selection.
Linux + LP = Windows with
After reading all (most?) of these comments, I’m considering Slackware. I plan to install it first on a 17 y.o. HP laptop (if possible) and go from there.
And the idea of “messing with /home” just seems over the top, I mean, if you want /home to be “portable”, you can mount it remotely. If you really want /home to be available anywhere in the world, then join Google Cloud or something.
I could write for days about my dislike of SystemD but instead I want to throw a potential life line to others. I haven’t read through all of the comments so forgive me if someone else has already mentioned this: For those of us who don’t want SystemD complicating our lives there is Devuan (https://devuan.org/). Its Debian altered by others (many from Debian ranks) who don’t believe we should have SystemD thrust down our throats.
IMO this is one more reason not to do SystemD. So “LONG LIVE ALTERNATIVES!!!”
:-)
(Warning: compliment ahead)
The Devuan people made a wise decission on starting the Devuan project.
They choose for actual making an alternative instead of saying/shouting “Don’t do that”.
I do respect them for making more then just one release and do hope many will follow.
“KEEP ALTERNATIVES ALIVE!!!”
Um, a microsoft-style registry is a database with highly obfuscated keys and values, not a series of files containing simple ascii text that can be manipulated like any other file.
This article can be condensed to “Lennart Poettering’s next target is PAM.”
Look upon my works, o ye mighty, and despair.
Poettiering needs to piss off. Another insane answer to a question that was never asked. Systemd may be just peachy for desktop, but it sucks for extremely large clustered systems, of which I have more than a few. This latest idiocy won’t work for my enterprise systems and will be disabled. Encrypted home directories are unreadable by anyone but the owner. Lots of companies won’t appreciate that at all. This kind of moronic bullshit makes me miss Solaris, AIX and HPUX.
I have been used Linux since the 90s and while there are all kinds of broken and bustered projects the entire intent of having things separate is so that we didn’t have to load every last stinking thing that wasn’t needed for it to operate. To me it seems like they are trying to cram too many things in that may or may not be necessary in regards to Home Directory management. I would think using a JSON file is like making it easier for someone to target data in one place to be able to hack a user. If you put all their passwords and the hashes in one file its like saying hey you get this stuff and its all in one place. One stop shop.
Linux itself was never meant to make it easier for other people to learn. It was designed around being able to add or subtract functionality. Hiding what goes on under the hood doesn’t do anything but make it easier for the core to be subverted. So you don’t want to learn what’s going on under the hood. Well too bad for you. The rest of us will continue to use Linux and you can go use MacOSX or Windows. That’s not being an asshole that’s just pointing out the fact that this operating system was built by people who value knowing how everything works. Will Ignorance isn’t going to absolve you from responsibility. We should be able to add or subtract things that are backwards compatible and not have to worry that it’s going to break because someone decided to change the architecture so much that it breaks the basics. I don’t see moving to SystemD as making any major advances. It’s like trying to make it more like Windows where it has bloated services that call other services. I can understand trying to make the home directories more secure. I can understand making it easier for programs to pull config info from one place but it’s not like INI files didn’t do that for windows and look where it went. Are you telling us you want a Registry for Linux? Good luck with that.
” … is equally automatic encrypted again as soon as the user logs out, locks the screen, or suspends the device.”
Well when its encrypted on the hard disk, its encrypted every time. Also when the user is logged in. But then the running software have access to the decryption layer. AND it also has access to it when the screen is locked or not. So there is no more security on if you lock your screen (Finally, even if the screen is locked, you want your programs to continue running in the background. Otherwise you can log out).
code what ever you want, but dont advertise it with fake features
> Why is it people bitch about how little they earn, always claiming their time is worth more, yet they don’t see when their time is being stolen by some piece of useless software
Sometimes that piece of useless software is the one marketed as a selling point in the computer’s marketing material. I think I’ve spent more hours arguing with useless OSes from One Microsoft Way, Redmond than anything built on the little kernel from Finland.
Lots of software I use, assumes Unix semantics such as symbolic links, returning integer file handles for all stream and datagram handle types, network stack behaviour, you name it. Some software can work with all kinds of kludges, some software won’t work at all. Yet, *BSD, MacOS X, Linux … no problem.
Given Microsoft seems to be in the throws of beating a path from the isolated wilderness they’ve found themselves in back to the POSIX land, I see no point in trying to support that pariah of an OS in my software. Want to run my stuff on Windows? You port it, I’ll accept the patches so long as they don’t break platforms I care about or make my code unreasonably difficult to maintain.
Thankfully, like many components of a computer, the OS can be replaced with something of the user’s choosing, and more open platforms are evolving every day.
But what about Xenix?
systemd will provide fantastic clickbait for many years to come.
Well, if we’re messing with how Linux directories work, I guess there’s no reason not to also look at GoboLinux?
While I don’t mind change?, and I applaud Pottering? I’m of the mind that systemd hasn’t had the time to mature enough for it to go about changing drastically, I also am not a fan of this idea of a “portable” home. Sorry,…..I guess I’m one of those old school grey beards who don’t think its a good idea, especially when you consider the network / access control nightmare that could bring:
“Hello?…IT Dept?….listen….whats the remedy for me losing my USB with my home folder?” (pause)…”No, I can’t really say WHERE I lost it, it might have been at my son’s college campus dorm this past weekend, or else it could be on the computer of my friend who was visiting from out of town.” (pause)…”So….you’re saying that my data could have been compromised?, and that since its not on the network and is in transit…there’s no way you can know if it has or hasn’t until it reconnects to the network? Oh…ok….thanks.” (final pause) “What?…..HR?……Monday morning at 9AM?…..ok…I’ll be there! thanks again!!”
And yes….I know networks are smarter, more secure, more robust than yesteryear, but there’s the old adage: If Someone Can BUILD It…..Someone Else Can BREAK It. And if you need any more proof of that statement,. just think about all the horror stories of “Smart” devices NOT doing what they were supposed to…..from Alexa cackling at you while you sleep, to Siri listening to everything you say, to smart doorbells getting hacked, to the AI in CARS being hacked! (and there’s video footage of cars having their brakes, their steering, and other important components hacked by drive-by hackers!) SO forgive me if I’m skeptical of this, and like I said…I know we’ve advanced, but just take a look at the movie “Wall-E” see those fat, slug-like creatures that can’t seem to stand up on their own two feet?…(due to decades of not DOING anything…..because computers have been designed to “do it all”) those creatures?…are what WE will become if we don’t reign things in a bit. I mean I can understand, say…..and un-manned / driverless drone….for weather or long range observation, but driverless cars?…..driverless TRUCKS?…..what’s next, pilot-less planes?….skipper-less submarines?….nah….at some point you have to stop, make a full-scope assessment and decide if the losses are worth the gains.
not all Linux users allow systemd on their Linux installs, many of us hold systemD and Lennart Poettering in contempt as a subversive, a interloper that is doing Linux and GNU FOSS a disservice, try antiX or Devuan, or if you want to see what Linux is under the hood try Slackware
Aah yes. The classic approach of solving a problem that doesn’t actually exist with additional complexity that you call simplicity and hope nobody notices.
Most systems aren’t multi-user desktops.
Haters might hate. People who use Linux to get work done will just continue not using systemd.
I’m already dreaming on my federated Home folder across 5 or 6 computers!
Since I have been using linux, I mean, since I downloaded the Linus Kernel and toyed a bit with it, there is one burning desire that I have had that was never realized.
I’ve always wanted a registry somewhere that I can screw up. You know, some key, value store somewhere in my home directory that I as a developer can stuff with all kinds of arcane data and obtuse GUIDs. Somewhere I can hide that one system setting I need to make my system useful or functional. I love digging thru layers and layers of configuration to find that one setting to make “list” the default instead of “details”.
I’ve always needed some kind of structure where I can misplace a caret or bracket to totally foo-bar my system, or a radical setting that looks close to what I want (oh! Could you PLEASE place it in the third layer of GUIDs?) that I change and my system will never boot right again!!!
Yes, a common place to store ALL of my user config sounds like a GREAT idea! Hey! How about we get done with HKCU and get started on HKLM? That sounds like a BOSS of an idea!!!!
Well, from my POV, the rationale for systemd was to create a better experience for laptop users. For (I suspect) the greater number of us hosting Linux on servers and desktops, it was a spurious change. An erstwhile ‘systemd-homed’ will be another spurious change, the tail wagging the dog. Trying to suck in sshd just adds to the joy.
Mr. Poettering and his team have already demonstrated is degree of – uh – “developer entitlement”, leaving me feeling that putting more and more system crap under one roof isn’t going to bite us in the okole.
I installed Ubuntu 18.04 n August 2018, and (on average) every 6 weeks systemd shit all over my hard drive, forcing a complete OS reinstall. This got old. I’m trying Devuan, but it has lots of warts.
If Microsoft isn’t paying the guy behind systemd, they probably should be.
I choose NO systemd because:
I would just like to know a program in the history of software that, without complying with the Unix philosophy, not be obsolete after 15 years.
All the current programs we use in the userland of a Unix system are decades old, of course over time they are updated, adapting to changes and they can do this because they comply with the Unix philosophy.
Like systemd, all “bloated” programs from the 70s, 80s, 90s, 2000s, etc. they have ceased to exist because “bloated” programs are expensive to maintain, because they do not adapt to changes and die.