Linux systemd-homed

TechRepublic has an overview of the functions provided by systemd-homed which facilitates portable home directories in systemd 245.

Apparently homed does not yet work with ssh logins (home directories are encrypted until you have logged in so the private keys in ~/.ssh are inaccessible during login).

I also wonder how it will integrate with a variety centrally managed (typically Kerberos based) authentication methods favoured by large enterprises (typical Redhat customers).

I have never seen portable home directories as a big issue to manage, especially with repositories becoming ever more popular.

It really does make you wonder how much territory Leannart wants to own... and when he will stop "adding value"...
 
Syncthing does the job as far as I am concerned.

Yet another unreal problem answered.

EDIT: syncing kernel, base, userland or installed packages across a high number of servers would have answered a real problem.
 
Oookay. Here we go again. Good thing I stockpiled on fire extinguishers, 'cause this is a flaming topic.

And the next value to add is bleedin' obvious: ssh. Somehow this mess with local ssh keys must be solved, managed, centralized. How dare user have them?

Okay, I'll go and have my first coffee of the day.
 
I'll be contrarian: It's actually a solution to a whole host of problems that a stock Unix (Linux, *BSD, Solaris, ...) install does not solve. For example: Secure the content of the user's data while they are not logged in by encrypting it. Or make it possible for a user to take their home directory with them to a different machine. Or make it accessible from multiple machines. And it centralizes /etc/passwd and /etc/shadow into a single file (also a good thing).

And it also creates a huge host of problems. How do you deal with multiple users being in a group, and having permission to read (or even write) each others files? Even when the other guy is not logged in? How do you backup a home directory, if it is encrypted much of the time? How do you deal with loss of the key server that's inherent in using LUKS (great new DoS attack and failure mode)? When a user moves their home directory from one place to another, how do you prevent inconsistent changes in the two different places? That's a problem that neither Coda nor AFS were ever able to solve.

And for each of the problems that this solves, there are already better solutions. Encrypting file systems, and encrypting disk hardware. Shared and cluster file systems, for data portability (with correct semantics for parallel access). Authentication management systems that solve the bifurcation between /etc/passwd and /etc/shadow, and so on and so on.

And in a tightly managed corporate environment, this whole thing just doesn't work. If an engineer in a big corporation takes his whole home directory and puts it on a USB stick, they will probably be fired on the spot, for violating a security policy. Long before they have time to plug that USB stick into a second computer. This while thing is one out-of-control software engineer trying to solve his little personal problem and his personal beef with systems, without thinking things through.

By the way, I love this completely ludicrous statement from the techrepublic article:
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.
Nonsense. It is exactly as hard as it was before. The only thing that systemd has accomplished is to move things around. Everything is in a different place, and has a different name. Certainly things are more centralized ... but before they also had naming conventions. A lot more configuring and administering is done by commands, rather than by editing config files; that is cosmetics, which doesn't change the fact that they still need to be configured and administered. And more importantly, the configuration and administration still needs to be thought through, which is the hard task.

There are other gems in the techrepublic article which demonstrate that the author has no clue (like: putting the /home directories on a different partition or disk drive for data durability? when the OS self-destructs? thats's ridiculous).
 
There are other gems in the techrepublic article which demonstrate that the author has no clue (like: putting the /home directories on a different partition or disk drive for data durability? when the OS self-destructs? thats's ridiculous).
... or maybe he is a seasoned linux user? I had systems self destruct, but that was around 1.x about. Maybe he prefers one disk per user, so write access does not count against the OS on it's SSD? Or he has no clue? Time will tell.
 
The average Linux user these days doesn't know what an SSH key is.
The average Linux user is a 15-year old Windows user who switched cause all his friends said it was so cool to do so and he wanted to be just like his friends. When he finds out he can no longer play his games (which is the only reason he even owns a computer) he jumps on a reddit forum and tried to figure out dual booting. After minutes--sometimes hours--of struggling with that, he formats his whole system and is back on Windows.
 
I'll be contrarian: It's actually a solution to a whole host of problems that a stock Unix (Linux, *BSD, Solaris, ...) install does not solve. For example: Secure the content of the user's data while they are not logged in by encrypting it. Or make it possible for a user to take their home directory with them to a different machine. Or make it accessible from multiple machines. And it centralizes /etc/passwd and /etc/shadow into a single file (also a good thing).

Didn't we have that already, with DCE/DFS?

No matter how far or how well-functioning that thing happened to be, from the architectural viewpoint it did address precisely the four basic tasks any OS is there to solve (file-, task-, user- and time-management) and put exactly these on a distributed scale. Seen that way, this was a very correct approach.
But then IBM and OpenGroup hosed it (probably due to not even fully understanding what they had there), and what we have now is a chaotic hay-wire of individual solutions.
 
Is it not also the case that systemD(umb) enforces the rule that users can't have anything running once they log out? So I guess this fits wonderfully. No more 'screen' processes hiding in the background you naughty users. SystemD's mantra surely is 'we know best how to run YOUR system.'

I also guess gnu has no concept of rbac because this would destroy it.

Finally, perhaps the answer to ssh is to not use it and invent a new swag of programs, probably called systemD-telnet or better still systemD-rlogin. LOL. 😂

Oh and excuse my ignorance but what happens if I as administrator need to access a user's directory to obtain a file they've supposed to have emailed to management but forgot before heading off on their 3 week tour of the Himalayas?🤔
 
The average Linux user these days doesn't know what an SSH key is. Perhaps it *is* best if someone more "capable" handles them for them.
Did this happen to you? Ask everyone to generate a key pair and send you the public key. How many private keys did you get? I paraphrase my boss' email on the subject "Send me you PUBLIC key. It ends in .pub. I will delete any private keys sent to me, and you'll have to generate a new key pair."
 
Oh and excuse my ignorance but what happens if I as administrator need to access a user's directory to obtain a file they've supposed to have emailed to management but forgot before heading off on their 3 week tour of the Himalayas?🤔
As I understand it, you as the administrator create the home directory container in the first place, and these containers allow for multiple LUKS keys to decrypt them, which means there'd be one or more admin/staff keys associated with home directories as well as the user's own key. I had the same question when I first read the article, and that was the conclusion I came to after some light research.
 
As I understand it, you as the administrator create the home directory container in the first place, and these containers allow for multiple LUKS keys to decrypt them, which means there'd be one or more admin/staff keys associated with home directories as well as the user's own key. I had the same question when I first read the article, and that was the conclusion I came to after some light research.

Thank you for that.
So, then the big question for me is: What's the purpose of encryption? If others hold a key to your data then you might as well not encrypt, surely? Or am I missing something?

Perhaps systemD boffins don't trust login credentials, file permissions, user groups, MAC, RBAC, ACLs and so on to protect a user's data? But then, hey a hacker could get root and unlock your user directories anyway. Oh no!!

My oh my, what a non-problem this software solves. Anyway, it's gnu/linux, once the issues count gets down to 400, they'll deem it obsolete and re-write it anyway, with even more bold, new ideas. Hilarious. 🤪
 
So, then the big question for me is: What's the purpose of encryption? If others hold a key to your data then you might as well not encrypt, surely? Or am I missing something?
That's a good question: Official(?) docs for systemd-homed/homectl.

It doesn't explain the reason for encryption in the first place in the "Storage Mechanism: luks Home Directories" section. That said, it also allows for other "storage mechanisms". It sounds like a mess, but maybe we're all wrong, and it will actually be less convoluted than we think?
 
Defense Information Systems Agency STIGs require USB storage devices to be disabled. Worked for DoD for two years and went through STIG reviews.
Same with big computer corporations. I know that if you insert a USB storage device into a corporate laptop of a certain big employer, it will (a) not work, and (b) you and your manager get an e-mail about a minute later, reminding you of security policies.
 
maybe the SSH thing can be solved with signed certificates. that way ssh won't have to read what's in ~/.ssh/{.pub file} .
 
Did this happen to you? Ask everyone to generate a key pair and send you the public key. How many private keys did you get? I paraphrase my boss' email on the subject "Send me you PUBLIC key. It ends in .pub. I will delete any private keys sent to me, and you'll have to generate a new key pair."

Haha. I didn't even get that far. Where I used to work, in the end I had to write a silly GUI tool for the other developers to use to generate their keys for version control. They would refuse to use a command line (Contrary to popular belief, Windows game developers are not the most worldly bunch when it comes to technology). So I had it send back to me their public keys.

This is something that shouldn't need to have been written ;)
 
Haha. I didn't even get that far. Where I used to work, in the end I had to write a silly GUI tool for the other developers to use to generate their keys for version control. They would refuse to use a command line (Contrary to popular belief, Windows game developers are not the most worldly bunch when it comes to technology).
Oh, I know. One of the most bittersweet memories of my career involves a middle-aged Windows developer who was very upset that Winzip wouldn't work on the Mac we were making him use.

Most folks told him to use the functionality built-in to Finder and ignored him, but I decided to try and help him 'cause I'm stupid like that. Turns out he was using Winzip to sort his dev tree by age and thus figuring out which files he had modified. I told him "all you need is git status. Try it." He grumbled something and wandered off. Later he came back to my desk and said "Jose that is amazing! That is exactly what I need! Thank you so much!"

Sweet because of how much time and effort I just saved him. Bitter because I wondered where the Hell he'd been working all his career. I know cvs has a "status" command. I suspect rcs does too, but I only used it briefly and a long time ago. Are there software shops out there that still don't use VCS? I kinda don't want to know the answer.
 
… portable home directories …

… were great, with Mac OS X, which I no longer use.

… If others hold a key to your data then you might as well not encrypt, …

Not everyone holds the key.

Whilst I work for an organisation, the organisation might hold a key for use in exceptional circumstances. Like, me kicking the bucket.


Some discussion including links to talks with Q&A: https://old.reddit.com/r/linux/comments/f23jht/-/
 
The average Linux user is a 15-year old Windows user who switched cause all his friends said it was so cool to do so and he wanted to be just like his friends. When he finds out he can no longer play his games (which is the only reason he even owns a computer) he jumps on a reddit forum and tried to figure out dual booting. After minutes--sometimes hours--of struggling with that, he formats his whole system and is back on Windows.
That was cruel... well, true but cruel...
 
That [The average Linux user is a 15-year old Windows user] was cruel... well, true but cruel...
Au contraire. Maybe cruel, but certainly not true. IBM paid $34 billion for RedHat. Their target was not 15 year old teenagers...

I don't work in IT any longer, but at the last place I did work, I helped retire a large fleet of Solaris systems, and replace (most of) them with Red Hat Linux virtual machines.

It's a common theme (and usually linked to cloud deployment options).
 
Not true. Only a small fraction of all computers (*) in the world are desktop/laptop machines, the vast majority of them sit in data centers. One of the cloud-scale hosters (the FAANG plus their Chinese equivalents) probably has more computers in their data centers than all of the world's laptop/desktop machines. Of the data-center machines, the vast majority are Linux (with a small fraction of Windows, and a vanishing fraction of other OSes, such as zOS = MVS + VM, AIX, Solaris, ...). Of the desktop/laptop machines, the vast majority are Windows, followed by Chrome, MacOS, with a tiny fraction (perhaps a few percent) being Linux. And that's before we start counting the many VMs in data centers.

Linux usage is completely dominated by data center.

(*) Footnote: When I say "computer", I mean something on which you can run programs, and that has a full-function OS, so I exclude deeply embedded IoT devices, and handhelds. Something you can typically get a shell on.
 
Back
Top