1. 26
  1.  

  2. 34

    This seems like a massive boondoggle and a potential security issue.

    1. 35

      That’s systemd for you.

      1. 6
        From The Collaborative International Dictionary of English v.0.48 [gcide]:
        
          boondoggle \boon"dog*gle\ v.
            [...]
             2. a useless, wasteful, or impractical project; -- especially
                one authorized by a government agency as a favor to
                partisans, to employ unemployed people, or in return for
                corrupt payments.
                [PJC]
        

        Today’s new word :)

        1. 8

          Wow, chown() on login. I trust that he’s right that chown()’ing the home dir recursively will happen extremely rarely, probably never for most people, and that the kernel would eventually add features to make it completely unnecessary. However, a (not so) quick find ~ | wc -l tells me I have 19 517 661 (19.5 million) entries which would have to be individually chown()’d. He says recursive chown is fast, but I imagine it’d take quite a while for me. Just listing all the files and piping to wc -l took 6 minutes.

          1. 2

            Maybe UID/GID namespaces could be utilized instead? One on-disk ID, preferably random-ish, one synthesized per system.

            That smells of WNT though.

            1. 1

              Just listing all the files and piping to wc -l took 6 minutes

              Did you do that >/dev/null? Otherwise, the bottleneck was probably your terminal emulator :)

              But yeah, if we’re talking single mount per home dir, I think the UID should be a mount option.

              1. 2

                As ClashTheBunny said, wc soaks up everything and the terminal emulator doesn’t print anything. The full command was sudo find ~ | pv | wc -l (sudo because some yocto stuff has weird permissions), where pv prints stats (total bytes read, bytes/sec, elapsed time) every second. pv should affect anything, since pv </dev/zero >/dev/null runs at 10 GiB/s.

                Now, with my CPU running at full speed (the previous times was from a downclocked CPU because I have TLP set to downclock when I’m on battery) and with warm disk caches, time sudo find ~ >/dev/null completes in 22 seconds and time sh -c 'sudo find ~ | pv | wc -l' takes 25 seconds. While those times are far more reasonable, they’re still fairly long (and I bet running chown on each entry would take significantly longer).

                1. 1

                  When you pipe to wc there is only summary output at the end, so it was all disk IO.

              2. 15

                I’m so glad I stopped using Linux after Systemd took over.

                1. 11

                  For me, systemd is actually the reason why I cannot stand Free/OpenBSD anymore. I don’t want to see another shell script for controlling important system software that might or might not work. Perhaps one of these days, OpenBSD pulls a typical OpenBSD move and some cool hacker reimplements the best parts of systemd (mostly the service administration really) into a single cohesive package.

                  1. 4

                    Funny because systemd and the pulseaudio situation with firefox are two of the reasons I switched from GNU/Linux to OpenBSD.

                    1. 1

                      pulseaudio situation with firefox

                      Mind elaborating on that? I use both and haven’t had any problems in years.

                      1. 2

                        Firefox no longer supports ALSA. ALSA has been fine for me for the past 14 years. I was unwilling to install pulseaudio and unwilling to switch to Chromium, so I moved to OpenBSD.

                      2. 1

                        There was a while ago when pulse audio and its Gnome controllers were shit and then it got good and I could just remote play or remote source really neatly and then that went away and I can only do normal stuff and it’s honestly kind of painless now.

                      3. 1

                        I quite enjoy having my boot process be shell-based. I regularly ^T it for information or ^C if I can’t be bothered to wait for something.

                      4. 4

                        What do you use now? What are the tradeoffs you had to make?

                        1. 2

                          I use Open, Net and FreeBSD as alternatives. For desktop and some server stuff I’ve used MacOS for a while. I’ve been using FreeBSD for a long time, and Open and Net on and off, but Systemd caused me so many problems that I’m almost completely off Linux. I have the odd throwaway VM here and there, and two hosts left running docker, one of which is going to be replaced with FreeBSD, the other retired.

                          I probably should’ve been clearer - I don’t use Systemd encumbered Linux as a primary OS anymore for anything important, and took steps to reduce the amount of Linux. Of course my phone is Android, so I’m still using Linux in some capacity.

                          The one tradeoff I’ve had to make with OpenBSD is that a lot of things are written for Linux, and because OpenBSD tends to do things in a more correct manner, things that don’t check to see something is there (e.g. /proc) tend to break. FreeBSD has better compatibility. On the other hand, OpenBSD is as rock solid stable as Debian used to be, which isn’t an indictment of Debian but really kudos to OpenBSD.

                          I have been surprised at just how good OpenBSD is as a daily driver Laptop. I use an X230 thinkpad with a custom BIOS and X220 keyboard as a personal laptop, and it’s really nice to use.

                        2. [Comment removed by author]

                          1. 6

                            well, then there are some sane options like slackware or gentoo left to use :>

                            1. 10

                              Void Linux, too.

                              1. 1

                                yes, my list wasn’t complete :)

                              2. 5

                                You also have the option of Devuan, Void Linux, Alpine, and GuixSD (all of which I’ve run as daily drivers at various points). I’ve also heard of Artix (which I haven’t attempted to run). The first two have worked in general in my experience. I run Alpine on my laptop (where I don’t need all the extra applications that would require libc), and Devaun on my desktop machine. Besides regular run-ins with PulseAudio stupidity, I’m pretty happy with it.

                                I did try OpenBSD in the past, but I have an nvidia card on my desktop (which isn’t supported), and on my laptop, it was uncomfortably slow to run a web browser. While I’m not inclined to run an OpenBSD desktop machine, I do have an OpenBSD webserver hosting my website, and I always pick OpenBSD implementations of tools if I have the option. At another point, I gave FreeBSD a shot, but it would occasionally boot without detecting my keyboard/mouse (due to an unsupported motherboard, or bug in the USB stack). The audio systems in BSDs are delightfully simple in comparison to Linux, though.

                                1. 3

                                  When Gentoo looks sane, we’re in a dark dark place ;)

                                  (and yes, Gentoo looks sane)

                                  1. 1

                                    …why?

                                2. 1

                                  I should’ve been clearer when I wrote the comment, I’m not fully gone. I still have two boxes running Docker, one on Ubuntu, one on Debian. The Ubuntu one is going to be replaced by FreeBSD, the Debian one will be retired when I get round to it. I also use Android, so I guess that counts too.

                              3. 6

                                This seems cool. One of the features mentioned was to “lock LUKS on suspend.” How is that problem currently solved? It sounds like a good compromise between security and avoiding shutting it down all the way when you’re not using it for an hour.

                                1. 3

                                  You have to put everything you need for decryption in an unencrypted place like a tmpfs before you destroy the keys on suspend:

                                  https://lonkamikaze.github.io/2014/04/01/geli-suspend-resume-with-full-disk-encryption

                                  (tbh, just opening a process that wouldn’t need to load from the encrypted disk sounds enough, all this tmpfs stuff is because that one was done with shell hackery instead of building a specialized application)

                                  1. 2

                                    Since this is only used for your home directory, and not your entire system, there really shouldn’t be any chicken-egg problem here. If your system partition is also encrypted, then its key can’t be clear from memory when you suspend (without tomfoolery with tmpfs), but as long as it’s just your home folder, all you need to do is make sure that you can prompt the user for their password without reading from their home folder.

                                    Considering that systemd already puts a user’s entire login session in a process control group and a mount namespace for user-segregated /tmp folders, it doesn’t even seem that hard. Just freeze the cgroup, unmount the home volume, suspend, and on resume prompt the user for their password, decrypt their home folder again, unfreeze the cgroup, and your back online.

                                  2. 5

                                    I’m still not seeing the use case for this. You stick your home diectory on a USB stick so you can keep your settings/config/rc when you move between systems? How does authentication/authorization work? Could anyone just plug in a USB stick and log into a computer with homed? What happens when they unplug the USB stick before logging out? Do the user/processes disappear? And when would you need this on a “normal” system?

                                    I’m really failing to see the advantages over cp.

                                    1. 3

                                      I’d assume their use case is a USB stick, with a built-in yubikey for authentication. It’d handle all the authentication and also provided a physical 2FA. I don’t know how I’d feel about employees all carrying them around town. There’s still a threat of malware getting on the USB in that case.

                                      Most of the systems I access, I don’t have physical access to, so “Home directory on a USB stick” doesn’t work.

                                      1. 2

                                        Yeah but what do they authenticate to? The buck has to stop at some point (especially if you don’t want user accounts sticking around forever).

                                        1. 1

                                          Yeah but what do they authenticate to? The buck has to stop at some point (especially if you don’t want user accounts sticking around forever).

                                          LUKS. The home folder is encrypted. If you don’t have the password, you can’t get at it.

                                          What happens when they unplug the USB stick before logging out? Do the user/processes disappear?

                                          Probably yes. Systemd already puts your entire login session within a cgroup, and when that session ends, everything inside the cgroup gets forcibly killed (a very controversial decision, of course). If the home volume unexpectedly vanishes, they can forcibly end every process that has access to it. The user entry in /etc/passwd probably disappears also.

                                          1. 3

                                            Yeah but what do they authenticate to?

                                            LUKS. The home folder is encrypted. If you don’t have the password, you can’t get at it.

                                            But what determines which decrypted home folders are allowed? If some random person plugs his encrypted USB stick into my computer, will my computer let him use it?

                                            Because if it does, then of course he’s able to execute a local root exploit (many more of those than remote root exploits) and now he has pwned my computer.

                                      2. 2

                                        I too struggle with the whole “portable” usb based home directory, but I can see a big use case for obviating UIDs away from the user’s concern and reworking NSS and all the other old style libc stuff for getting user based information and authentication.

                                      3. 3

                                        Am I the only one here that has not used a USB stick in forever? I would not even know where I have one immediately.

                                        1. 3

                                          What (desktop) Linux painfully needs is a way to cordon access to specific applications. Why does chrome get to read everything that’s in my home directory? No practical reason for that, but it’s a huge security risk. It didn’t look like systemd-homed would be tackling this, but if they did, it would be a massive improvement.

                                          1. 2

                                            Can we please please please – regardless of what else this does – add the path to the user’s config/profile dir to this “JSON user record”?

                                            1. 2

                                              I really like the idea of a guest mode I can enable or disable. If I’m okay with sharing my compute hardware with people who have physical access to it anyhow, I’m happy for them to have a secure way of feeling ‘at home’ if they trust me.

                                              1. 2

                                                Why don’t they fork the kernel and use strings for user identifiers? Let me spell it: keep the existing API intact.

                                                Rule number 1 of making money by providing software to IT: do not ever touch to an interface that is used by big company.

                                                1. 1

                                                  This all sounds great, except for varlink.

                                                  1. 1

                                                    Just a random idea, could a home on a USB stick be handled via unionfs mounts?

                                                    1. 16

                                                      Problem with USB sticks with that setup is that they really are meant as “save file here time to time” kind of device. Using them like hard disk wears them down unbelievably quickly and they tend to have only one failure mode: catastrophic failure. (I am working on a project where we do exactly this and we found it out hard way)

                                                      1. 3

                                                        A lot of this can be fixed by using flash filesystems rather than something designed for disks. Built-in wear-leveling goes a long way to keeping blocks from going bad.

                                                        1. 1

                                                          TBH we didn’t try proper flash filesystems at any point because USB stick wear patterns were so inconsistent. Some of them would take days, even weeks of constant abuse until failure. Others failed in half an hour. I think in total we have burned through probably closer to 100k usb sticks at this point. Curiously Kingston usb sticks were always the crappiest of them all, in endurance and also in read/write performance. Also, there are huge differences between manufacturing batches so we cannot just trust some manufacturer, not even custom orders straight from the factories. At some point we came to conclusion that getting non-IT people to use Vagrant with very rudimentary management gui (https://github.com/digabi/naksu) is more safe than booting from usb medias!

                                                      2. 1

                                                        Yeah, why not