Will Systemd 245 Bring Major Changes to Linux's Home Directory Management? (techrepublic.com) 345
Camel Pilot (Slashdot reader #78,781) writes: Leannart Poettering is proposing homed to alter the way Linux systems handle user management. All user information will be placed in a cryptographically signed JSON record, such as username, group membership, and password hashes. The venerable /etc/passwd and /etc/shadow will be a thing of the past. One of the claimed advantages will be home directory portability.
"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," writes Jack Wallen at TechRepublic. "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."
What is not clear is that for portability, systems would have to have identical user_id, group names, group_id, etc. And what mechanism is going to provide user authorization to login to a system?
"At the moment, systemd 245 is still in RC2 status," the article notes, adding "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."
"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," writes Jack Wallen at TechRepublic. "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."
What is not clear is that for portability, systems would have to have identical user_id, group names, group_id, etc. And what mechanism is going to provide user authorization to login to a system?
"At the moment, systemd 245 is still in RC2 status," the article notes, adding "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."
Who put this one guy in charge? (Score:5, Insightful)
Re:Who put this one guy in charge? (Score:5, Funny)
By the looks of everything he's written, Microsoft. Can't wait for all of /etc to be merged into one single binary. The editor will be a docker container that takes up about 400mb of space.
Re:Who put this one guy in charge? (Score:4, Interesting)
Re: Who put this one guy in charge? (Score:3, Interesting)
Yeah, but no need for elaborate conspiracy theories. He's just a deluded individual who has found a niche in self-promotion as the "future of Linux" Too bad - as you point out - that he does.not understand the deep structural, fundamental principles rooted in Unix that were defined by people clearly smarter than him
Re: Who put this one guy in charge? (Score:5, Insightful)
I no longer use Linux (FreeBSD servers, macOS laptop), so I can't say I'm fully up-to-date, but I don't understand this line of thinking. I mean, to me personally everything you and others have said here seem to make sense (negatives such as reliance on binary data and systemd daemons, deviating from the "unix way," etc.).
BUT, systemd has been adopted as default and required by pretty much every single major distribution out there, correct? There are an awful lot of smart people developing for Redhat, Debian, etc. That all of these distros have adopted systemd with remarkably little dissent means something, right?
Re: Who put this one guy in charge? (Score:5, Insightful)
It means that, similar to Windows, having just ONE known configuration at the core of things makes a lot of work much simpler.
Just because people are smart and intelligent doesn't mean they can't fall into the trap of thinking, "Damn, this made my job ten times easier. Let's keep it."
Re: Who put this one guy in charge? (Score:4, Interesting)
That would sort of make sense if you were describing the utility of an optional LaunchD-like service for keeping daemons running on bare hardware.
It's absolutely bonkers when we're talking about adding USB portable home directories to an init system that's supposed to run inside a docker container whose sole purpose is to spin up a 200 loc microservice - or in any number of other configurations ranging from a cell phone to a car to an AI platform and most importantly all the uses neither of us have ever thought of.
Standardizing on a fixed configuration means sacrificing long term innovation in favor of short term convenience. It's exactly how Windows one the desktop and lost everything else.
Re: (Score:3)
So if I read this all right, Linux is just a kernel and systemd is the remaining userland which now generally goes with that kernel?
Re: (Score:3)
There is some sanity left in the world with Slackware.
Re: (Score:3)
"the world of Slackware" was almost lost a few months ago when Patrick could no longer live on thoughts and thank-yous alone. If you support this sanity, show it by joining his patreon. It's still only about 500 people and the future of the world of Slackware still isn't totally certain.
Re: Who put this one guy in charge? (Score:5, Informative)
Redhat, Debian, etc. That all of these distros have adopted systemd with remarkably little dissent means something, right?
REMARKBLY LITTLE DISSENT? Were you not paying attention when Debian originally even mooted making systemd the default? And then when it became the primary supported 'init' ? Sure, Debian *developers* seem to be all over it (and I have some sympathy for their reasons, it's in some ways solving problems for package developers), but it's a royal pain in the ass from a sysadmin point of view.
I could put up with having a shim of it when Debian still had the viable option of using a SysV init instead, but in Buster (current stable) I found that even on a somewhat minimal server there was just too much with a literal dependency on systemd as init that it's no longer possible. That lead to me spending most of a frustrating day, and then an hour or two per day for the next week, sorting out the mess of converting over and ensuring things were both working and working how I actually wanted.
I mean, yeesh, what's with moving over to using system timers instead of good old cron jobs, especially when you had a nicely working cron + root's crontab + anacron setup for serial running of daily tasks, instead leaving it up to system timers to run each thing "some time" between the defined hours, so no idea when it might actually be, and things might try to run in parallel that shouldn't ?
I'm still facing doing the "convert to systemd" dance for the major set of VMs I'm responsible for where others make use of them, and then the upgrade to Buster, and at this stage I'll seriously be contemplating investigating any gotchas from just moving it all over to FreeBSD.
systemd, and remember it's not just the replacement PID 1, but all sorts of tentacles in network setup, dns resolution, login handling, and now this /home proposal, might have solved some issues with making desktop environment integrations work more smoothly, but it's an utter clusterfuck of badly reinvented wheels when it comes to server systems administration.
And then there are the bugs, and poor design decisions. Any longterm /. reader will have seen stories about those over the years. That hilarious facepalm about taking any failure to parse for a 'user' in a system unit and deciding it means "run it as UID 0". Long since fixed now, BUT COME ON TAKE SOME FUCKING CARE WHEN YOU'RE CODING SUCH CORE SOFTWARE.
Re:About "invalid user id meaning root" (Score:4, Interesting)
WTF. That whole exchange comes off as a guy way out of his depth.
I've been fairly ambivalent about systemd, but if thats the guy whos in charge holy fucking shit.
Re: (Score:3)
That is just...painful to read. It's some weird combination of cover-your-ass and arrogance.
Re: (Score:3, Interesting)
Re: Who put this one guy in charge? (Score:4, Informative)
svcs was well designed by sane, experienced, people.
Re: (Score:3)
There was a time when there was more to a distro than the widgets and wallpaper but few current distros seem to have got the message. Where are the new Knoppix's? You know, the real cool ideas.
What we're really looking for is an OS where every command is a REST API call. Although I admit there is room for a competitor in the form of GraphQL.
Re: (Score:3)
My post have been somewhat of an appeal to authority (though again, I don't use Linux--I personally don't have any stake in this argument), but I would say it was more a question of authority--why do the authorities like systemd when it seems to get raged against every time it pops up on Slashdot?
You say it's a complete disaster. By what metric? Has systemd hurt Linux in the user market? In the developer market? In the server market? In the VM market?
I use FreeBSD for my servers -- I made my choice my years
We didn't think it was a conspiracy theory. (Score:4, Interesting)
I don't think anyone was assuming it's a conspjracy theory. Are you one of those, who see conspiracy theorists everywhere? Lurking in the shadows... Under the table... In the closet... ;)
Careful. You might cause a self-fulfilling propecy there.
I generally take the scientific duck typing approach here. At a certain point, it's not really relevant if Microsoft hired him, or he just fell into their Kool-Aid Man as kid like Obelix, or he just behaves the same for completely unrelated reasons. If the behavioral pattern is the same, then the same name is used. A window is a window, whether it's a square glass pane in a brick wall or a round plexiglass disc in a steel wall. :)
Re: (Score:3, Insightful)
He's just a deluded individual who has found a niche in self-promotion as the "future of Linux"
Based on the number of Linux distributions who are wholesale adopting his software it seems he's not the deluded one.
Re: Who put this one guy in charge? (Score:4, Funny)
Based on how many people buy water that costs more that gasoline and complain about the cost of gasoline, I wouldn't be so sure.
Re: Who put this one guy in charge? (Score:5, Insightful)
Yeah, I'm going to disagree.
There are no sacred cows. Anything can be changed as needed. Decisions taken in the 1970s may have made sense back then, but don't necessarily apply anymore. So simply the fact that "Unix is traditionally this" doesn't matter to me in the slightest.
Re: Who put this one guy in charge? (Score:4, Interesting)
If you want to clean up some 1970s remnants we could start with /bin /sbin /usr/bin /usr/local/sbin /usr/X11R6/bin etc etc. That was because the size limitations of a DEC RK05 disk pack. There is no reason to have binaries randomly split into directories like that.
Re: Who put this one guy in charge? (Score:4, Insightful)
bin vs sbin makes sense to me - one for superuser/system stuff, one for programs a user would likely run directly.
Same with the top level vs /usr/ vs /usr/local - stuff required to boot (so small partition maybe?) then general multiuser stuff from os package manager, etc. then in /usr/loca/ stuff you've compiled, locally customized stuff, etc.
Is that needed today? No not really. But that doesn't mean you should break 40 years of convention and change it.
Re: (Score:3)
Because the systemd ones are tuned for the likes of Amazon to use directly over Xen in their deployments, so they can then turn around and sell it back to you.
These changes aren't about making your life easier as a user or a developer, but about how Linux can be made to depend on corporate life support.
You're going to be forced to use it anyway, might as well stretch out your throat now.
Re:Who put this one guy in charge? (Score:5, Insightful)
n/t
No one. He does what he wants, and it's up to the actual people in charge to adopt the things he plays with. Why are you so angry at someone tinkering rather than those people who are adopting his toys?
Why? (Score:5, Insightful)
Why?
Re:Why? (Score:5, Funny)
Re: (Score:3)
Sounds like he "discovered" kerebos and want to poorly implement it.
Re:Why? (Score:4, Interesting)
Or you could just copy your home directory onto a flash drive using even an ancient copy of Linux (just new enough to know what USB is).
Nobody in their right mind is going to allow their system to accept login creds stored on a flash drive that was just plugged in by the would-be user of that flash drive. Consider, do you want me using your PC just because I happened to have a flash drive with my home directory, uname, and password on it?
Re: (Score:3)
If any major companies adopt this, they would have to be extremely retarded.
Wonder how doing this with root would work
Re: (Score:2)
When you imagine engineers to be that stupid, it is a pretty good indication you have no clue what the actual technical issues are.
Re: (Score:2)
When you imagine engineers to be that stupid,
I don't think they are stupid, I think they are smart. Rather they don't understand elegance, which is fine for Microsoft but not for Unix.
Re: (Score:2)
What exactly does it mean "it will work"? Does it "work" currently on one machine? What will not work if I move it it to another machine apart from possibly different UID/GID?
Btw, we have roaming profiles in Windows. Perhaps it works if you have infinite bandwidth.
Re: (Score:3)
Awesome. Never mind that I'd rather just use SSHFS to grab what I need from either system and do my best to keep them separate anyway.
But the BS inthe summary about having your /home on a portable drive and plugging it in back and forth, but then the note about "same userid number and gid number" ... well, guess what? It has worked that way for a VERY long time, before systemd.
WTF.
Registry (Score:5, Funny)
All user information will be placed in a cryptographically signed JSON record, such as username, group membership, and password hashes.
Hopefully Poettering will provide some kind of proprietary "Editor" for this "Registry" of information, as other similarly well-designed systems do.
Re: (Score:3)
Choosing JSON is a bit of a WTF. Presumably you're going to have to either use canonical JSON, which makes it entirely non user editable. 'J' is from the world of browsers and all the bad things that go along with it.
YAML would be slightly more tasteful but the same problem with canonicalization exists. Clearly nothing was learned from X.509.
The alternative is to encrypt only the decoded value fields, so it's immune to format changes but that leaks all sorts of metadata unless you're really careful with you
Re: (Score:3)
How else are JavaScript developers going to contribute to the OS? Do you expect them too learn C??
Now we just need to get working on porting the kernel to node.js.
Re: (Score:3)
Considering the project already provides specific tools to deal with things like the journal, i'm sure they are aware of the need.
Just keep him the fuck away (Score:5, Insightful)
from *BSD.
Thanks in advance.
When will people end his tyranny (Score:5, Insightful)
he's removing the unix from unix--and not even subtly.
Re: (Score:3)
he's removing the unix from unix--and not even subtly.
The more important question is whether he's doing it well. It's lacking elegance.
Re: (Score:2)
Re: (Score:2)
he's removing the unix from unix--and not even subtly.
More to the point -- we're letting him ("we" being the the community and vendors).
Re:When will people end his tyranny (Score:4, Funny)
why? (Score:5, Insightful)
You could easily transport your /home/USER directory between home and work,
this will most likely get you fired in all but the smallest companies...
Re: (Score:3)
this will most likely get you fired in all but the smallest companies...
Why? Because we aren't transferring it over the cloud? A few years ago I would have agreed with you. Everything was about network lockdown, disabling USB mass storage, and making it difficult to transfer files. These days? Hey if you cloud the cloud on your one drive you can access all your super secret stuff from this unsecured mobile while you smoke clouds!
Re:why? (Score:4, Insightful)
So, "Jim" takes his home directory home for the weekend. "Jim jr. installs crazy warez from eastern Europe to allow him to unlock new levels in the latest game (and a few less helpful things he doesn't know about). On Monday, Jim takes his warez and trojan ridden home directory back to work. On Tuesday, his work announces new layoffs due to business losses related to some kind of data breach...
Re: (Score:3)
UID/GID (Score:3)
Re:UID/GID (Score:4, Funny)
Re: (Score:3)
Based on what systemd has historically been playing with, I would assume he seized upon the fact that modern linux can have different uid namespaces that remap uids and differenet mount namespaces.
So hypothetically, one user logs in and their 'native' homedir uid is 1000, then a new mount namespace is created and that user is given say uid 1002 and the uid is remapped as appropriate. Meanwhile user 2 logs in who also has uid 1000, then it can still make a new namespace and say make that user effectively us
Re: (Score:2)
It sounds to me like riding a bike with your hands crossed - all perfecty reasonable in theory.
When it gets to situations like this it would be better throw out the whole UID/GID approach and start over. The original system served us well and was simple, if these added shenanigans were part of the original requirement then presumably another solution would have been used from the outset.
Re: (Score:2)
It sounds to me like riding a bike with your hands crossed - all perfecty reasonable in theory.
Yes, the current way of dealing with this (managing UIDs by hand so that users have the same ID everywhere) is a lot like riding a bike with your hands crossed; it works fine at low speed, if you're careful.
This is a step in the right direction. Ultimately, if I'm authenticating with a system, I should be able to also tell it what home directory use, and it would be nice to be able to change the directory arbitrarily at runtime. And it is low cost, just replace the kludgy parts of the UID system with a sta
Re:UID/GID (Score:4, Informative)
I'm just explaining how I presume LP would have proceeded in such an endeavor.
You no longer have to presume. If there's a problem, they do a chown -R. This is not a joke. [linuxreviews.org] Then there's no longer a problem.
This will break all sorts of things (Score:5, Insightful)
What about: NFS; daemons that put things into user's $HOME; sysadmins who want to put things into a user's $HOME; users that are created but are not for real people; what happens when LUKS goes wrong or I do not want the LUKS over head or the system dies part way through encrypting a $HOME, ...
I hope that there is a way to opt out from this latest systemd nightmare.
One of the nice things about Unix is that it is simple and robust. Poettering is introducing fragility by means of complexity.
Re: (Score:2)
No more differential backups, only the entire container.
Except now that it is portable, do we go back to syncing a full backup at login time when the user needs to start doing things?
Can't really schedule it in the middle of the night if the flash drive is offline and sitting in the pocket of their pants in the washing machine.
I guess since the cheapest possible USB flash sticks people buy are so reliable and durable, backups won't be needed... /s
So wait a second. If my home dir is encrypted until login, b
Re: (Score:2)
So wait a second. If my home dir is encrypted until login, but my SSH keys can't be read to login and decrypt my SSH keys... How does one remotely login?
Oh, don't worry, systemd-remoted will replace ssh I'm sure one day...
I joke, but that's probably what it would take. Basically have multiple 'slots' for the decryption key, sealed to your ssh private key, an ssh-agent could prove loging by successful decypt of the data encryption key.
Re: (Score:2)
No more differential backups, only the entire container.
I can 100% guarantee you that you've misunderstood what this does.
Re:This will break all sorts of things (Score:5, Informative)
So wait a second. If my home dir is encrypted until login, but my SSH keys can't be read to login and decrypt my SSH keys... How does one remotely login?
Funny you should ask: Lennart's reply [reddit.com]:
SSH mostly works fine already in the current codebase: the only restriction is that something has to unlock the homedir once so that ssh can work. Thus if you have a laptop you want to log into via ssh, just log in locally first, and maybe put the screen lock on. And then ssh just works, until you fully log out locally, again.
Re: This will break all sorts of things (Score:5, Interesting)
Nice post Alan. As all old-timers here know, I'm a BSD neckbeard and I am increasingly getting calls from people about moving away from Linux. Such a shame, (I've nothing against Linux - it's amazing; just not my competency zone) but this guy Poettering just seems intent on making a living by proposing "solutions" for things that ain't broke and them implementing them in an incomplete and unnecessarily complex way.
Re: This will break all sorts of things (Score:3)
Frankly, he is like an inexperienced child with the ego of a massive cocaine addict.
It seems he has not learned any of the decades of lessons Unix was built on, nor does he care. He just tramples over everything, breaking everthing, and when it inevitabely comes crashing down, he just doubles down, like Trump.
Constructing an ever bigger and more rigid model of reality that he can't get out of, as he would admit to have been an idiot. Nobody can accept that. Not even to themselves.
Being from a family of psyc
Re: (Score:2)
I certainly hated it when admins put things in my $HOME.
I was more thinking about servers, not desktop stuff - where, yes, your $HOME is yours to do as you will. Your account on a web/... server is there because you need to do a little work there occasionally. I think that this shows that there is not a 'one size fits all' approach.
Not a good idea IMHO (Score:5, Insightful)
How many copies of the home directory floating around on thumb drives is the average user going to create? This reminds me of Segal's law:
A man with a watch knows what time it is. A man with two watches is never sure.
By making it easy to thoughtlessly carry all your data around on thumb drives and install copies made at different times on random systems, you're never going to be quite sure which version(s) on which drives or systems have that one critical file you're looking for.
It seems to me that it would be better to have a master system with the "official" copy of your home data, and a utility to sync home drives from other systems against that. This also would not require messing up how users, groups and passwords have worked for the past five decades.
Re: (Score:2)
How many copies of the home directory floating around on thumb drives is the average user going to create? This reminds me of Segal's law:
A man with a watch knows what time it is. A man with two watches is never sure.
That's why I always wear at least three watches, usually five, and smash/replace any watch that disagrees with the majority. Yes, yes, I go through a LOT of watches, but it's worth it.
Pottering is to Linux as Ajit Pai is to the FCC. (Score:2, Interesting)
Re: (Score:2)
Pottering is to Linux as Ajit Pai is to the FCC.
That is extremely unfair to Mr. Pai.
Stupid, Stupid, Stupid (Score:3)
While I've been indifferent to the rest of systemd (much of it I really like, too), this has to be the single dumbest idea in the history of dumb ideas. There are no benefits above what we already have, and a metric tonne of new, irreconcilable problems this will cause.
Stupid, stupid, stupid.
Re: (Score:2)
I feel the same way. Some thing systemd does it actually does well. This sounds horrid and a giant step backwards.
God Poettering, you really want me to hate you (Score:2)
I used to hate systemd. Now after using it and understanding more or less why it does what it does and how, I sort of changed my mind: I kind of vaguely like it. Well not really, but it's easy enough to live with. See, I'm a reasonable man, I try to adapt.
And just as I finally got over my intense dislike, you drop this shit on me? Seriously???
Systemd had better keep the fuck away from my home directory. Don't fucking encrypt it, and don't stick your data in it. I swear to God, if systemd so much as touches
Re: (Score:2)
I used to hate systemd. Now after using it and understanding more or less why it does what it does and how, I sort of changed my mind: I kind of vaguely like it. Well not really, but it's easy enough to live with. See, I'm a reasonable man, I try to adapt.
My understanding from reading things is that the idea behind systemd isn't the problem, it's the implementation and some of the design choices. (Kinda like with Windows)
Meh.. (Score:3)
So this is a concept that the late 90s would have loved if they had the USB flash drives of 2020 and no other advances. When computers were heavy and expensive and being able to sneakernet your home directory around would have been great if such storage were convenient, fast, and large enough.
Now, between most common personal computers being laptops and internet synchronized content making your content everywhere you want to be anyway, it's a bit antiquated.
Now it represents a step in the wrong direction for security. Security has been focusing on skipping the password in favor of more contextually adaptive strategies (like TOTP, usb keys, even combining TPM with easier PIN, fingerprint, or camera for physically local access) and keys for remote access. This strategy as currently conceived always requires your password. So it is only for linux desktops that like to move home directory around... I don't see a huge interest in this..
Re:Meh.. (Score:5, Informative)
Sun also had something similar in the late 1990s with their SunRay terminals. You kept a smart card on you and any terminal you logged into would load your desktop and profile. They worked pretty well. It's funny when people "discover" old ideas. Hey how about we have one big server and then cheap clients with limited processing power? Brilliant! No one has ever thought of that before!
Screw you Poettering (Score:3)
There is no need for this. If it ain't broke, don't fix it.
Who was asking for this? (Score:2)
If you're a dev, use git. If you're not a dev and you're technical, use git. If you're not technical, you didn't know you had a home directory anyway and your family who set you up on Linux is taking care of it for you anyway.
Is he going to provide a registry editor? Will there be a 32 and 64 bit version just like Windows? How will this handle UID/GID mapping? Is there a crypto key that needs to be signed to say this home +
Re: (Score:2)
Re: Who was asking for this? (Score:2)
Rsync
Actually cp works too
Re: (Score:2)
I remember wanting something like this... in 2003 or thereabouts.
But it’s now 2020, and there are better ways to do this. Who wants to plug in a flash drive every time they want to start working? Not to mention that my home directory on a server is somewhat different than it is on my workstation, even if it shares some elements... and is different on my Macs than on my Linux boxes.
Maybe Poettering is secretly trying to drive all of us over to BSD? But he does ostensibly work for Red Hat, doesn’t
Re: (Score:3)
Redhat makes money by selling support. Coincidence?
Am I the only one? (Score:2)
I just checked (Score:2)
my home directory on the machine I'm typing on is about 263G
there is a /home on my NAS that runs about 3T
there is a /home on my tiny little server that is about 70G (files being served)
The only good thing is they're all the same uid/gid so I can nfs my way around them.
Which one should I carry around on a memory stick? and why would I want to?
Maybe he should just release the systemd/OS (Score:4, Insightful)
He wants to move everything from Unix/Linux/BSD into the systemd "kernel", so why not just fork the world and call it systemd/OS? Then he's free to add whatever strikes his fancy, without the pesky restrictions of compatibility.
Overengineering nonsense (Score:4, Informative)
That's nonsense. I'm sure that my situation is quite common:
- My company forbids me to put anything on a usb stick, or connect any external usb stick (for security reasons).
- My company solves the moving between systems problem by having my home directory on a NFS, simple and easy.
- For my company it's easier to provide all developers with a portable computer that can be taken to home and work using a vpn.
- My work computer has already a encrypted hard disk, why to encrypt something that is already encrypted.
- I don't want to mix my personal home directory on my personal computer with my work computer. I want to keep my things private and my work data secure.
- What about group permissions, setuid and setgid, sudo permissions, symbolic links, etc.
This will create a complicated mechanism where it is not needed. Don't remade things just because you have a cool idea.
Hmmm. Lets see (Score:2)
Avahi was not a bad implementation, but has not been integrated far enough.
And systemD has been so-so, but I think that this will be jumping the shark.
Re: (Score:3)
Pulse Audio has pretty much failed.
Failed at what? It certainly seems to have *not* failed at being the default sound engine for nearly every desktop Linux distribution out there.
Completely asinine (Score:3)
I've never before heard a more ridiculous, crippling proposal being taken so seriously.
I ssh into every linux (and most windows) systems I run. My primary linux workstations at home and at work both run web servers serving my home directory. Why would I ever want to go back to the early 1980's and prior "put in your floppy disk" workflow?
If I cannot avoid this nonsense I'll either have to do my own distro, fork linux, or choose a BSD. This may just force me over the line that systemd is treading ever so closely.
Size... (Score:2)
Home directories can and often do get huge. Like a usb drive (that isnâ(TM)t say a 5TB removable) is going to be able to cope?
That and home directories often end up intertwined with other parts of the system - shared folders and the like.
What problem is this 245 thing supposed to solve?
Portable flash drive (Score:2)
How many people are still carrying data in portable flash drives? Your whole home? Is systemd going to modernize to 2005?
Seriously, this is a solution in search of a problem. And the problem does not exist.
This is dangerously stupid and here's why ... (Score:4, Insightful)
I have never done a profane post on slashdot ... Until now!
WTF?!
This means that my 718GB home directory, which takes 5 minutes and 15 seconds just to do: /home/saneuser
du -sh
will have to be decrypted when I log in? And, reencrypted when I log out?
Does this mean it will take 10 minutes to login and 20 minutes to logout?
What happens if an emergency system shutdown is done?
What happens if my system crashes? Is everything lost?
What happens if I want a different password on each of my systems?
What happens on a Raspberry Pi system (e.g.) that only has a small micro SD card? Does the needless decrypt/encrypt wear out the drive prematurely?
And, what about other small realtime/embedded systems? Do they [have to] suffer with this crap?
Will the user have full R/W permission access to all files under their home directory? Or, will some root owned file/directory get dropped there that can't be modified by the user?
What about delta backups of all user home directories to backup media? This will make them huge.
What happens if the login/authentication data in the home directory gets corrupted?
GET THE FUCK OFF MY LAWN!!!
Re: (Score:3)
There is something around here that is dangerously stupid, but it's not homed.
I already addressed most of these points. Encryption and decryption take place when the files are copied, not every time the user logs in or out. TFA is incorrect about that.
What if the system crashes? Same things as on other systems. Open files will likely lose any unsaved changes.
If you want a different password on different systems? Then do so, nothing is stopping you, or forcing you to move your home folder around. It's an opt
Re:This is dangerously stupid and here's why ... (Score:5, Interesting)
I just pulled the -rc2 and looked at the homed subdir.
It is some 18,000 lines of code with only 482 comments. That's just shoddy. It has a coding style that I've never seen before, that violates most sensible style guides.
So, it has the same crappy/amateurish (poor quality) coding style that L et. al. are noted for. That's why systemd took years to shake out the bugs [that should never have been there in the first place].
The code quality hasn't improved much in the ten years since systemd was first dropped [when I first examined it]. That's really quite depressing, actually.
L et. al. have also, time and again, proven themselves impervious to bug fixing, releasing [obviously] untested code full of bugs, refusing to even acknowledge bugs, even when presented with solid unit tests (by highly competent core [kernel] developers) that unequivocally demonstrate the bugs.
L et. al. spend more time "complaining" about "whiners" than they do fixing bugs.
I believe that's why Linus [publicly] refused to take any more kernel patches from them.
Note that this isn't about whether the "idea" is good or not. It's about the implementation of systemd having bugs.
And, I've been programming for 45+ years [in the kernel/driver/realtime space], written a lot, and examined much more.
This code base's ugliness just makes me cringe [again].
Maybe, conceptually, there's a good idea here. But, L should stick to ideas, and let the adults in the room do the coding.
Based on L's proven track record, nobody can/should trust this code base until it's refactored/vetted by professionals [other than him].
Re: (Score:3)
You know that encryption in any reasonable system is done in real time, right? My 1 TB laptop boots and logs in just in a few seconds. Because obviously it doesn't rewrite 1 TB of stuff once I decrypt the disk.
We're not talking about rewriting the entire disk. We're talking about forgetting the keys when the account is not in use. So that if somebody grabs your screenlocked laptop, all your stuff isn't there in the open just because you didn't shut it down.
Re:This is dangerously stupid and here's why ... (Score:4, Insightful)
The core issue with this proposal is that any task that needs to read the unencrypted version of /home/username is going to need the users password. This is a major problem for SSH (as mentioned in the article), and just about any backup or rsync job. Generally, the backup job doesn't know user passwords for security reasons.
I can't see how this change works with group shares. Where is the master list of group members stored, and how are the passwords authenticated?
Any utility that bypasses the usual login mechanism, like samba, will have a hard time. For files in a home directory, does samba return the encrypted file or decrypted file? or different things depending on the users login state? How does this work if a different user-id is accessing the files as part of a group share or backup job?
From a security point of view, a single JSON file containing the passwords is vulnerability. Any process that accesses that JSON file for any reason becomes a potential security problem (either for denial-of-service attacks or to permit unauthorized access.) This is one of the key reasons why passwords were moved from /etc/passwd to /etc/shadow. Many fewer processes need to modify /etc/shadow.
The per-computer /etc/passwd file ensures that only users authorized on a particular computer can login. Consider the problem of a file server. All the /home directories on the network are stored on the file server, however many networks permit only admin users (a subset of the user base) to login locally on the file server. This avoids issues where a single user logs into the file server directly, and creates a security problem.
The /etc/passwd, /etc/group and /etc/shadow were developed the way they were because it satisfies a great number of common use cases. It concerns me that the entire article drops the functions associated with /etc/group.
Re:This is dangerously stupid and here's why ... (Score:5, Insightful)
This means that my 718GB home directory, which takes 5 minutes and 15 seconds just to do: du -sh /home/saneuser
will have to be decrypted when I log in? And, reencrypted when I log out?
I strongly doubt that. I'm sure it would use fscrypt, so your directory contents would actually always be encrypted on disk, and would be decrypted on the fly when read and re-encrypted on the fly when written. What would actually happen when you log in is that the encryption key would be loaded into the fscrypt kernel module and when you log out the kernel would be told to erase the key.
Many systems (especially ARM-based, but I expect Intel/AMD to catch up soon) now include an Inline Crypto Engine (ICE) that offloads the encryption/decryption work from the main CPU, making the encryption and decryption completely "transparent" from a performance -- and even power usage -- perspective.
From a security perspective, the cryptographic signature on the $HOME metadata is absolutely essential. I'm sure you'd have to load the relevant key onto each machine where you want to use your $HOME, and the signature, verified by that public key, would tell the system that it should trust the assigned uids and gids in the portable $HOME. I suppose it could even provide a per-system mapping between the uid/gid values used in the portable file system and the values used by the OS, so you wouldn't have to make them consistent across systems, but just be sure that the mapping was correct on each new system.
Many have complained that we already have solutions for these problems, with network-shared directory contents. Yes and no. I can see where that signed metadata solves a lot of problems with current shared-directory solutions. That said, I'm not sure it's worth diverging from the standard *nix approach, and I suspect that there are lots of tricky corner cases, especially around security.
We need a registry too. (Score:2)
Sooner or later this will come into being.
But for now, having been using it since MCC 0.99pl13, I think I will have to abandon Linux and return to BSD for some sanity.
I hate what Linux is becoming under the covers.
uh, no thanks, never, ever, ever (Score:5, Interesting)
First, this issue was solved a very, very long time ago with NFS and Kerberos. When I was an undergraduate (an embarrassing number of decades ago now), you could walk up to any of hundreds or perhaps thousands of computers in the network, log in, and you had your home directory there. Not a copy, not a replica, your home directory, mounted via NFS and authenticated via Kerberos. It worked beautifully.
The systemd re-invention of beautiful technology sounds utterly brain-dead.
Let's see... you want to be able to walk up to ANY other systemd-enabled machine and plug your USB drive in. Seriously? Am I the only one that thinks that's a really, really bad idea? Shouldn't you have some basic bar to be able to trust a machine, like having it carry a login page you recognize, having it be in a building you frequent, having it be in an office you normally use? If so, then aren't those machines on a network that you already trust? So why the frell would you walk around with THE ORIGINAL VERSION of your home directory on a USB drive that could be lost, damaged, stolen, corrupted, etc?
Stop re-inventing the wheel. Just stop. Read and learn about what's gone before. Often those ideas are pretty damned good. (And the ideas from systemd seem .. how to put this? ... not so good.)
Already running systemd-245 (Score:3)
And, hopefully, that's one service that will never be found!
BSD? (Score:4, Interesting)
I've started to wonder, for various reasons, about BSD.
Is it time to take a serious look at it?
How practical and good is BSD these days? Would all my favorite imaging, video editing, gstreamer filters, 3D, deep ML, and science number crunching software run fine on some flavor of BSD? Would HTML and the latest OpenGL and WebGL and Vulkan and OpenCL work fine? Would such a machine be decent to deal with for maintenance and upgrading? Do I have the time to try it out? (no.) Who uses BSD these days, and how well does it work for them?
Does the BSD world have their version of Leannart Poettering?
Re:BSD? (Score:5, Informative)
There's Theo. He can apparently be pretty abrasive. But, unlike Poettering his technical direction is usually spot on. Though of course OpenBSD is particularly opinionated in many aspects of its design, but when he wanted to do things his way, he had to do them in OpenBSD. He didn't inflict it on NetBSD or FreeBSD. If only Poettering had done the same, then it could have succeeded or failed upon its own merits, rather than by bullying and politics.
GhostBSD is supposed to be pretty decent for desktop use. Not had time to try it myself. I previously tried PC-BSD and FreeBSD on the desktop. Both work, but required a bit of manual setup (nothing worse than Linux a decade back). Today, FreeBSD uses copies of the Linux graphics drivers and has the usual Mesa drivers, so Radeon graphics works pretty much as you would expect; OpenGL works just fine, Vulkan and OpenGL should too, but I haven't personally tested them. nVidia have drivers too, but no CUDA support.
Overall, it's a bit less slick than modern Linux. But it's functional. The FreeBSD pkg/ports collection is as large as what you have in Debian/Ubuntu. If you want more control over your system, it's increasingly the better choice. On the non-desktop side, I've fully switched over.
increasing the need for support (Score:3)
Let's take the works of Poettering, he managed to get ALSA to the back seat, driving sound with Pulse Audio. Things got very messy before they started working okay. We gained nothing essential. On paper, we got networked sound. But, when I tried it between wired systems, I found out that my wireless Android phones and tablets got disturbed, all wireless got the handbrake on.
Oh, and since there's really a hit and miss on gapless audio playback. On KDE, there was no issue before, but everyone went for the VLC or gstreamer backend for Phonon, and VLC is too focused on video. Don't know why gstreamer didn't work. So for several years, since the start of acceptance of Pulse until a few years ago (a decade or so) it took a lot of fiddling to get gapless playback working. Not sure how bad it is today on a fresh install.
Then came systemd, which stepped away from a number of UNIX practices for not always convincing reasons. Lots of changes, new ways to learn to do things that were, to most, not broken. Since those making my distribution supposedly had their work made easier, I just went with it.
But it does have me wonder, what's the purpose of such changes. All I can think of, if it's not the competition making/promoting these changes (donning my tin foil hat just in case), it's likely the companies making money with support.
And as much as red hat has done for Linux, they are not my friend, considering Jim Whitehurst (CEO) and other management members never even used Linux on their desktop.
I'm all for promoting Linux on the desktop, for the home user, since that's the easiest way to obtain digital independence (yes, you BSD guys rock, but I can't recommend BSD to a Windows user looking for a way out), and I don't think you're very credible in that light if you make money with Linux but can't be arsed to use it...
Re: (Score:3)
If you don't like systemd then don't use it.
This sounds good until an important part of the system like the window manager gets written to require its API.