Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Linux

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."
This discussion has been archived. No new comments can be posted.

Will Systemd 245 Bring Major Changes to Linux's Home Directory Management?

Comments Filter:
  • by ludux ( 6308946 ) on Saturday May 02, 2020 @01:37PM (#60015030)
    n/t
    • by ArchieBunker ( 132337 ) on Saturday May 02, 2020 @02:11PM (#60015216)

      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.

      • by QuietLagoon ( 813062 ) on Saturday May 02, 2020 @02:33PM (#60015302)
        }}} ... By the looks of everything he's written, Microsoft. ... {{{ --- Oddly, I was thinking the same thing a short while ago. GNU/Linux is looking to be more and more opaque the more Leannart Poettering adds to it.
        • 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

          • by Moridineas ( 213502 ) on Saturday May 02, 2020 @03:18PM (#60015494) Journal

            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?

            • by Calydor ( 739835 ) on Saturday May 02, 2020 @03:40PM (#60015566)

              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."

              • by medusa-v2 ( 3669719 ) on Saturday May 02, 2020 @04:29PM (#60015766)

                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.

                • 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?

            • There is some sanity left in the world with Slackware.

              • "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.

            • by Athanasius ( 306480 ) <[gro.yggim] [ta] [todhsals]> on Saturday May 02, 2020 @05:30PM (#60015950) Homepage

              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.

              .... and breathe.

            • Re: (Score:3, Interesting)

              by rodia ( 1031082 )
              Let's look at Linux stake holders' view on systemd:
              • Regular users shouldn't care too much, probably don't even notice.
              • Advanced users (admins, geeks, e.g.) are divided on the issue, to put it mildly.
              • Developers get a standardized user space system services interface, probably makes their lives easier.
              • Distro maintainers get uniform system structure and service/machine management. Makes their job somewhat easier for now, much easier after competing init systems/system standards have been abandoned (which
          • by BAReFO0t ( 6240524 ) on Saturday May 02, 2020 @03:47PM (#60015588)

            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)

            by thegarbz ( 1787294 )

            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.

          • by vadim_t ( 324782 ) on Saturday May 02, 2020 @04:28PM (#60015756) Homepage

            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.

            • by ArchieBunker ( 132337 ) on Saturday May 02, 2020 @07:50PM (#60016282)

              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.

              • by i.r.id10t ( 595143 ) on Saturday May 02, 2020 @08:00PM (#60016300)

                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.

    • by thegarbz ( 1787294 ) on Saturday May 02, 2020 @04:20PM (#60015710)

      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)

    by TFlan91 ( 2615727 ) on Saturday May 02, 2020 @01:38PM (#60015044)

    Why?

    • Re:Why? (Score:5, Funny)

      by phantomfive ( 622387 ) on Saturday May 02, 2020 @01:59PM (#60015140) Journal
      Because now you can put your home directory on a flash drive, move it to somewhere else, and it will work. Because apparently in the past it didn't work, the ones and zeroes on one filesystem were incompatible so it melted your hard drive if you tried that.
      • Sounds like he "discovered" kerebos and want to poorly implement it.

      • When you imagine engineers to be that stupid, it is a pretty good indication you have no clue what the actual technical issues are.

        • 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.

      • by rastos1 ( 601318 )

        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.

      • 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)

    by Kunedog ( 1033226 ) on Saturday May 02, 2020 @01:41PM (#60015062)

    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.

    • 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

      • by AmiMoJo ( 196126 )

        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.

    • "Hopefully Poettering will provide some kind of proprietary "Editor" for this "Registry" of information, as other similarly well-designed systems do."

      Considering the project already provides specific tools to deal with things like the journal, i'm sure they are aware of the need.
  • by Kernel Kurtz ( 182424 ) on Saturday May 02, 2020 @01:47PM (#60015076)

    from *BSD.

    Thanks in advance.

  • by Anonymous Coward on Saturday May 02, 2020 @01:48PM (#60015086)

    he's removing the unix from unix--and not even subtly.

  • why? (Score:5, Insightful)

    by edmatt ( 6774562 ) on Saturday May 02, 2020 @01:49PM (#60015088)

    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...

    • 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)

        by sjames ( 1099 ) on Saturday May 02, 2020 @05:52PM (#60016014) Homepage Journal

        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...

  • by bugs2squash ( 1132591 ) on Saturday May 02, 2020 @01:49PM (#60015090)
    It sounds less scary put like it is in the article than replacing the whole UID/GID paradigm which presumably it would have to do. Who is to say that the "dev" group on one machine is the same as the "dev" group on another regardless of the numerical ID it carries.
    • Re:UID/GID (Score:4, Funny)

      by phantomfive ( 622387 ) on Saturday May 02, 2020 @02:05PM (#60015174) Journal
      homed solves this problem by doing chown -R on the entire directory if it detects a discrepancy. So it's elegant.
    • by Junta ( 36770 )

      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

      • 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.

        • 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

  • by Alain Williams ( 2972 ) <addw@phcomp.co.uk> on Saturday May 02, 2020 @01:50PM (#60015096) Homepage

    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.

    • by dissy ( 172727 )

      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

      • by Junta ( 36770 )

        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.

      • No more differential backups, only the entire container.

        I can 100% guarantee you that you've misunderstood what this does.

      • by Xolotl ( 675282 ) on Sunday May 03, 2020 @05:39PM (#60018838) Journal

        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.

    • by Bearhouse ( 1034238 ) on Saturday May 02, 2020 @02:42PM (#60015340)

      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.

    • 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

  • by Waffle Iron ( 339739 ) on Saturday May 02, 2020 @01:52PM (#60015110)

    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.

    • 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.
  • by StormReaver ( 59959 ) on Saturday May 02, 2020 @01:58PM (#60015132)

    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.

    • I feel the same way. Some thing systemd does it actually does well. This sounds horrid and a giant step backwards.

  • 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

    • 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)

  • by Junta ( 36770 ) on Saturday May 02, 2020 @01:59PM (#60015144)

    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)

      by ArchieBunker ( 132337 ) on Saturday May 02, 2020 @02:40PM (#60015336)

      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!

  • by sconeu ( 64226 ) on Saturday May 02, 2020 @01:59PM (#60015146) Homepage Journal

    There is no need for this. If it ain't broke, don't fix it.

  • I was unaware there was a "I need my home directory on a thumb drive" movement.

    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 +
    • Even for the non-technical, there are is a way to get the needed bits of your homedir on a flash drive. We have had it for years: FILES. My biggest objection to this increase in complexity is that it comes at a cost of distance from your own data. "JSON record" instead of simple flat files? Distance from your data.
    • 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

  • Am I the only one that wants things to remain as they are? init.d/upstart/systemd added a huge level of complexity to solve a problems that I didn't have. I don't have a problem moving or syncing my home directory between machines and I really don't want to have to edit a JSON file to prove that my files are mine. /rant
  • 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?

  • by WoodstockJeff ( 568111 ) on Saturday May 02, 2020 @02:11PM (#60015214) Homepage

    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.

  • by Wainamoinen ( 891945 ) on Saturday May 02, 2020 @02:15PM (#60015232)

    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.

  • Pulse Audio has pretty much failed.
    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.
    • 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.

  • by sylvandb ( 308927 ) on Saturday May 02, 2020 @02:23PM (#60015262) Homepage Journal

    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.

  • 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?

  • 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.

  • by Forever Wondering ( 2506940 ) on Saturday May 02, 2020 @02:59PM (#60015414)

    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.

    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:
    du -sh /home/saneuser

    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!!!

    • 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

      • by Forever Wondering ( 2506940 ) on Saturday May 02, 2020 @08:28PM (#60016380)

        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].

    • by vadim_t ( 324782 )

      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.

      • by Cassini2 ( 956052 ) on Saturday May 02, 2020 @07:13PM (#60016206)

        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.

    • 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.

  • 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.

  • by pz ( 113803 ) on Saturday May 02, 2020 @04:07PM (#60015646) Journal

    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.)

  • by sensei moreh ( 868829 ) on Saturday May 02, 2020 @06:11PM (#60016060)
    My Fedora 32 system is running systemd-245.4-1.fc32.x86_64

    ~$ rpm -q systemd
    systemd-245.4-1.fc32.x86_64
    ~$ systemctl status homed
    Unit homed.service could not be found.

    And, hopefully, that's one service that will never be found!

  • BSD? (Score:4, Interesting)

    by darenw ( 74015 ) on Sunday May 03, 2020 @12:13AM (#60016796) Homepage Journal

    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)

      by rl117 ( 110595 ) <rleigh@ c o d e libre.net> on Sunday May 03, 2020 @03:48AM (#60017068) Homepage

      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.

  • by aRTeeNLCH ( 6256058 ) on Sunday May 03, 2020 @04:48AM (#60017140)
    Am I the only one who has the feeling that Red hat (now owned by IBM) is more and more pushing for a system that needs the right style of specialist to maintain it?

    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...

What we anticipate seldom occurs; what we least expect generally happens. -- Bengamin Disraeli

Working...