• ancap shark@lemmy.today
    link
    fedilink
    arrow-up
    191
    arrow-down
    6
    ·
    7 months ago

    What you’re refering to as Linux, is in fact, Systemd/Linux, or as I’ve recently taken to calling it, Systemd + Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning Systemd system made useful by the Systemd corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX

  • Olap@lemmy.world
    link
    fedilink
    arrow-up
    130
    arrow-down
    16
    ·
    7 months ago

    When does systemd stop? Linux without it is increasingly looking unlikely in the future. Are we not worried about it being a single point of failure and attack vector?

    This isn’t a moan about the unix philosophy btw, but a genuine curiosity about how we split responsibilities in todays linux environment.

    • NateNate60@lemmy.world
      link
      fedilink
      arrow-up
      178
      arrow-down
      14
      ·
      edit-2
      7 months ago

      SystemD will consume the entirety of Linux, bit by bit.

      • In 2032, SystemD announces they’re going to be introducing a new way to manage software on Linux
      • In 2035, SystemD will announce they’re making a display system to replace the ageing Wayland
      • In 2038, the SystemD team announces they’re making their own desktop environment
      • In 2039 SystemD’s codebase has grown to sixteen times its size in the 2020s. SystemD’s announces they’re going to release replacements for most other packages and ship their own vanilla distro.
      • In 2045 SystemD’s distro has become the standard Linux distribution. Most other distros have quietly faded away.
      • In 2047, SystemD announces they’re going to incorporate most of GNU into SystemD. Outrage ensues from the Free Software Foundation, which vehemently opposes this move.
      • In 2048, Richard Stallman dies of a heart attack after attempting to clone SystemD’s git repo. SystemD engages in a hostile takeover and all resistance within the FSF crumbles
      • In 2050, SystemD buys the struggling RedHat from IBM for $61 million.
      • In 2053, most world governments have been pressured into using SystemD.
      • In 2054, Linus Torvalds, fearing for his life, begins negotiations to merge kernel development into SystemD
      • In 2056, the final message on the Linux kernel development mailing list is sent.
      • In 2058, Torvalds dies under suspicious circumstances after his brand-new laptop battery explodes.
      • In 2060, SystemD agents assassinate the CEO of Microsoft.
      • In 2063, after immense pressure from SystemD-controlled human rights organisations, Arch developers discontinue development.
      • In 2064, the remaining living Debian developers release the next stable version of their clandestine and highly illegal distro.
      • taladar@sh.itjust.works
        link
        fedilink
        arrow-up
        35
        ·
        7 months ago

        I think you might want to recheck the ages of some of the people in your timeline, most of them aren’t that young anymore.

        • NateNate60@lemmy.world
          link
          fedilink
          arrow-up
          4
          arrow-down
          13
          ·
          7 months ago

          Yes, because it’s easier to take care of octogenarians than people who might actually put up a fight to having their laptop batteries replaced with a pipe bomb.

        • TheGrandNagus@lemmy.world
          link
          fedilink
          English
          arrow-up
          17
          ·
          7 months ago

          Debian in many ways isn’t as slow-moving as people think.

          For example, they moved to Wayland by default (for Gnome anyway) in 2019. A number of well-known distros likely won’t have that until 2025/2026 or beyond.

          • 0x0@programming.dev
            link
            fedilink
            arrow-up
            5
            arrow-down
            1
            ·
            7 months ago

            Sadly they’ve been dropping archs throughout the years, meaning they’re no longer the distro you can use to run on “anything” from a pi to a mainframe…

            • yoevli@lemmy.world
              link
              fedilink
              English
              arrow-up
              2
              ·
              7 months ago

              Doesn’t trixie still support like a dozen arches? I think one of the more recent deprecations was MIPS BE which is functionally obsolete in 2024, at least insofar as practically no one is using it to run a modern distribution.

              • CrazyLikeGollum@lemmy.world
                link
                fedilink
                English
                arrow-up
                2
                ·
                7 months ago

                Bookworm, Trixie, and Sid all currently support a total of 10 different architectures.

                And looking through the Wikipedia article for Debian’s version history, most of the dropped architectures were functionally obsolete when they were dropped, or like the Motorola 68000, when support was added. (notable exceptions being IA-64 which was dropped 4 years before intel discontinued it, SPARC which is still supported by Oracle, and PowerPC.)

              • 0x0@programming.dev
                link
                fedilink
                arrow-up
                1
                arrow-down
                1
                ·
                7 months ago

                If your bar is “modern distribution” stick to Ubuntu.

                If you want to maintain older hardware Debian used to be a go-to solution.

      • NekkoDroid@programming.dev
        link
        fedilink
        arrow-up
        11
        arrow-down
        14
        ·
        7 months ago

        One way to notice a person has “systemd derangement syndrome” is by looking at how they write systemd: if they write it SystemD they are already in late stages of SDS and it isn’t curable anymore.

    • mogoh@lemmy.ml
      link
      fedilink
      arrow-up
      42
      arrow-down
      4
      ·
      7 months ago

      By this logic the Linux kernel is also a single point of failure and attack vector.

      sudo isn’t going away, so does doas. run0 is just another alternative to use or not.

      There are still distribution out there without systemd and if there ever won’t be any systemd-free distributions left and systemd would become a critical part of the Linux ecosystem, then it would get the same treatment as the Linux kernel with many professional maintainers.

      • cole@lemdro.id
        link
        fedilink
        English
        arrow-up
        1
        ·
        7 months ago

        plus, it isn’t like this isn’t exactly like adding another “door” to the “systemd building”. It’s a modular component of systemd, so more akin to replacing the sudo building with a new, but still separate, systemd sudo building

    • Cooleech@mstdn.plus
      link
      fedilink
      arrow-up
      9
      ·
      7 months ago

      @Olap
      I agree. As someone who uses systemd on daily basis (I use Arch, BTW 😄) I really like it, but I am a bit worried about it being a single point of attack. Maybe just push doas as default instead? I never used doas but I watched few videos about it, so I guess it’s fine and probably better than sudo (less bloated).
      Just my few cents.

      • taladar@sh.itjust.works
        link
        fedilink
        arrow-up
        13
        ·
        7 months ago

        I don’t see how something would be inherently easier to attack if it is called systemd-foo instead of just foo. Attack surface and vectors do not depend on which project develops a particular tool.

    • 0x0@programming.dev
      link
      fedilink
      arrow-up
      7
      arrow-down
      2
      ·
      7 months ago

      Gentoo, Slackware and Devuan can be used without svchost for linux.

      They’ll only stop when they rebrand it to systemd OS.

      • notabot@lemm.ee
        link
        fedilink
        arrow-up
        2
        ·
        7 months ago

        Debian works fine without systemd too, there’s a page on the wiki on how to install without it, or remove it after the fact.

        • rcbrk@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          7 months ago

          Easy with sudo apt remove --purge --allow-remove-essential --auto-remove systemd:

          The predictable failure of things towards the end of apt running the above command. Still in a gnome terminal, but the apt script couldn't even complete due to a bunch of stuff now missing

          Uh-oh.. a black vt on reboot, complaining that no inittab found..

          :-D Time to go outside.

        • jkrtn@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          7 months ago

          A lot of debs add services to systemd, do those just skip that part?

          • notabot@lemm.ee
            link
            fedilink
            arrow-up
            1
            ·
            7 months ago

            They seem to. Debian explicitly supports multiple init systems, sysvinit being the primary alternative, so packages have to handle systemd-init not being there.

    • drwankingstein@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      5
      arrow-down
      5
      ·
      7 months ago

      Systemd is a bit of a hassle to be rid off, but thankfully it’s not actually that hard, the hardest part I found was converting systemd services to whatever init system I use.

      • TrickDacy@lemmy.world
        link
        fedilink
        arrow-up
        13
        arrow-down
        7
        ·
        7 months ago

        I wonder how many hours you sunk into that practicality-free, weird-philosopy-dependent project

        • notabot@lemm.ee
          link
          fedilink
          arrow-up
          5
          arrow-down
          1
          ·
          7 months ago

          Probably not much time, a lot of packages come with init scripts anyway, and they’re pretty trivial to write if not.

          You can certainly argue it’s a philosophical choice, I’d say it’s more down to recognising the many poor architectural choices in systemd, rubbing agaist its many pain points and misfeatures and being alarmed at the size of the attack surface it exposes. I understand there is an effort underway to reduce the size and complexity of the main shared library to help address the last point, but just the fact that is necessary shows the scope of the problem.

          • TrickDacy@lemmy.world
            link
            fedilink
            arrow-up
            4
            arrow-down
            4
            ·
            7 months ago

            Systemd is fine. If it wasn’t, most distros wouldn’t have switched to it years ago.

            • notabot@lemm.ee
              link
              fedilink
              arrow-up
              3
              arrow-down
              2
              ·
              7 months ago

              Let’s agree to disagree on that point. Redhat switched because they invented it, and so took all the RHEL derivative distros with them. Debian switched to prefer it after a rather contentious vote and so took all the Debian derivative distros, including Ubuntu, with them. That just leaves a lot of the smaller distros, most of which seem to have stuck with sysvinit or similar as far as I can see.

              • TrickDacy@lemmy.world
                link
                fedilink
                arrow-up
                1
                ·
                edit-2
                7 months ago

                The arguments against systemd are very unconvincing but more importantly, there is zero evidence that they actually matter.

                And it works.

                Further, in order to represent this as a nearly unilateral decision you failed to mention that arch, centos, and opensuse all opted in independently.

                And no offense but angry Internet randos arguing software philosophy will never convince me to disagree with the creator of the Linux kernel.

                Linus Torvalds said:

                “I don’t actually have any particularly strong opinions on systemd itself. I’ve had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues.”

                • notabot@lemm.ee
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  7 months ago

                  I obviously find the arguments against systemd more persuasive than you do, and that’s fine, it’s all open source and we can all make our own choices about it. My experience with it over the years has been, and still is that it vastly over complicates things that used to be simple, often the less commonly used parts just don’t work right (the automounter is a particular bugbear of mine, and few distros seem to use the network management component). The arguments do matter in practical terms as they directly impact how it works.

                  Of the distros you mentioned, centos is a RHEL derivative and so wasn’t independent, arch packages multiple init systems, but yes, I’d forgotten opensuse, and they seem to be firmly in the systemd camp.

                  I may be an internet rando, but I’m not actually angry, more just disappointed. I’d agree with Mr Torvald’s opinion that some of the design details are insane, but I think they are more fundamental than just ‘details’ as many are to do with the fundamental concepts around what systemd is and how it works. Linus can be a real dragon around changes to the kernel, but he’s always tended to be more relaxed about the layers above it.

                  That the developers of systemd are ‘much too cavalier about bugs and compatibility’ is surely clear to anyone who follows the relevant mailing lists and bug trackers, and should alarm everyone.

        • drwankingstein@lemmy.dbzer0.com
          link
          fedilink
          English
          arrow-up
          1
          ·
          7 months ago

          took me about an hour to get started with artix originally, and maybe a couple more to really familiarize myself with the init. As for practicallity, it’s been a large improvement for me.

    • TheGrandNagus@lemmy.world
      link
      fedilink
      English
      arrow-up
      26
      arrow-down
      2
      ·
      edit-2
      7 months ago

      I mean it should kind of already be something like GNU/SystemD/X11/PipeWire/Linux, I guess.

      It’s not like the GNU utils are the only massive integral part of the OS. I think GNU/Linux caught on squarely because many people follow Stallman, and that’s how he wants people to refer to it.

      • fruitycoder@sh.itjust.works
        link
        fedilink
        arrow-up
        1
        ·
        7 months ago

        It definitely made way more sense at early on. I mean GNU made most of UX of using Linux at some point. Systemd, and the browser now make a much bigger portion than before, and the world is more than GNOME now too.

    • Lexi Sneptaur@pawb.social
      link
      fedilink
      English
      arrow-up
      46
      arrow-down
      27
      ·
      7 months ago

      Systemd makes life easy. It also makes Linux more teachable. I like accessibility and don’t even mind this

      • topperharlie@lemmy.world
        link
        fedilink
        arrow-up
        26
        arrow-down
        7
        ·
        7 months ago

        hard disagree. life with plain text logs and daemon init scripts was so easy and nice. But we can’t have nice things…

        • atzanteol@sh.itjust.works
          link
          fedilink
          English
          arrow-up
          35
          arrow-down
          3
          ·
          7 months ago

          Those hacked together system-specific bash scripts were shit. Having a standard way of creating, starting, ensuring restarts,and logging services is so much better.

          You can still get all the plain text logs you like.

          • baru@lemmy.world
            link
            fedilink
            arrow-up
            7
            arrow-down
            1
            ·
            7 months ago

            Those hacked together system-specific bash scripts were shit.

            With a different feature set per script as well. The systemd service files have often been pushed upstream.

            Pretty sure people liking those scripts never really tried dealing with them across distributions. Though this just rehashes things that were said when distributions decided if to switch to systemd. Still the same strange claim that those scripts are somehow easier. It wasn’t, it is also way easier to package a systemd file from upstream than to maintain that stuff within a distribution.

          • trevor@lemmy.blahaj.zone
            link
            fedilink
            English
            arrow-up
            5
            arrow-down
            1
            ·
            7 months ago

            How do you get plain-text logs instead of the garbage binary format that journalctl forces on you?

            • 2xsaiko@discuss.tchncs.de
              link
              fedilink
              arrow-up
              14
              ·
              7 months ago

              Set ForwardToSyslog=yes in journald.conf and install a syslog daemon. Also optionally Storage=volatile (I wouldn’t set Storage=none unless you want systemd to no longer show you any logs anywhere including in systemctl status because I assume it will do that)

            • atzanteol@sh.itjust.works
              link
              fedilink
              English
              arrow-up
              5
              ·
              edit-2
              7 months ago

              By configuring journald to forward messages to syslog as is the default.

              “forces on you” 🙄

              Edit: Systemd has been around for 14 years. Did you never think to google this?

        • TimeSquirrel@kbin.social
          link
          fedilink
          arrow-up
          22
          arrow-down
          3
          ·
          7 months ago

          You know what’s nice? Being able to sit down at any Linux distro and being able to set up and configure services without Googling how to use that particular distro’s init system.

      • herrvogel@lemmy.world
        link
        fedilink
        arrow-up
        22
        arrow-down
        5
        ·
        edit-2
        7 months ago

        But it’s so unbearably slow.

        Me when my computer that has a typical uptime of 37 days boots up in 7 seconds with systemd instead of 5.5 seconds with runit: 😡😡😡😡

      • lengau@midwest.social
        link
        fedilink
        arrow-up
        5
        arrow-down
        1
        ·
        7 months ago

        I’m not on the systemd hate train by any means, but I don’t understand how this is any improvement over pkexec

        • NekkoDroid@programming.dev
          link
          fedilink
          arrow-up
          3
          ·
          7 months ago

          I don’t understand how this is any improvement over pkexec

          That has the same problem as sudo: the SUID bit is set for it.

          The fact that run0 uses polkit is more of a byproduct that this kinda authentication is already done with polkit all over the place in systemd. You can have individual subcommand accessible to different users (for example everyone can systemctl status, but systemctl reboot needs to be in the wheel group) which is why its generally used within systemd already. And it wouldn’t surprise me if again you can do it with this as well, limiting what commands can unconditionally run, need prompt or are completely blocked.

        • pingveno@lemmy.ml
          link
          fedilink
          English
          arrow-up
          1
          ·
          7 months ago

          I’m unclear from the documentation, does pkexec work under non-GUI contexts?

          • lengau@midwest.social
            link
            fedilink
            arrow-up
            6
            ·
            7 months ago

            As long as you have polkit setup to work in terminal sessions, yes. This is pretty standard these days, though not particularly widely used.

  • KISSmyOSFeddit@lemmy.world
    link
    fedilink
    arrow-up
    76
    arrow-down
    5
    ·
    7 months ago

    It’s still missing core functionality for an init system, like a display server protocol, compositor, desktop environment and web browser smh.

    • jkrtn@lemmy.ml
      link
      fedilink
      arrow-up
      13
      arrow-down
      1
      ·
      7 months ago

      If we could get an LLM that uploads all our data along with an ad server in our desktop apps, then we’d really have something going.

    • baru@lemmy.world
      link
      fedilink
      arrow-up
      15
      arrow-down
      3
      ·
      7 months ago

      Systemd isn’t just an init system. It is a project with low level building blocks for a distribution. Most of the complaints are that it isn’t just an init system, while it’s not meant to be just an init system.

    • d3Xt3r@lemmy.nzM
      link
      fedilink
      arrow-up
      28
      arrow-down
      4
      ·
      edit-2
      7 months ago

      Agreed, this is a nice inclusion. I also hate sudoers with a passion - I already use doas but it’s not standard (in the Linux world anyway), but with systemd providing an alternative means that it’ll become a standard which most distros would adopt, and I hope this means we can finally ditch the convoluted sudoers file once and for all.

        • NekkoDroid@programming.dev
          link
          fedilink
          arrow-up
          9
          ·
          edit-2
          7 months ago

          The thing with this is: its just a symlink to the systemd-run binary, which talks to PID1 to spawn new processes (in separate cgroups IIRC). Its one of the most fundamental parts of systemd. Even the debian systemd package includes systemd-run.

          I guess the other question is if some tools the distro provides might switch to supporting it by default. For example on Arch there is makepkg that should never be executed as root, but does internally call some things with elevated privileges (mostly pacman to install and remove packages). Currently it checks for sudo and if not falls back to su, but maybe it might be worth considering changing su for run0 if its guaranteed to be there.

            • NekkoDroid@programming.dev
              link
              fedilink
              arrow-up
              4
              ·
              7 months ago

              it does its authorization with polkit (which IIRC defaults to allow all wheel group members) and giving users that shouldn’t be allowed root access, root access, is not something you ever want. This is usually referred to as unauthorized privilege escalation. Also, it isn’t like sudo doesn’t need configuration.

        • d3Xt3r@lemmy.nzM
          link
          fedilink
          arrow-up
          34
          ·
          edit-2
          7 months ago

          doas is quite popular in the BSD world, and was ported to Linux a few years ago (via the OpenDoas project).

          For starters, it’s is a lot smaller than sudo - under 2k lines of code vs sudo’s 132k - this makes it lot more easier to audit and maintain, and technically less likely to have vulnerabilities.

          Another security advantage is that doas doesn’t pass on the environment variables by default (you’d have to explicitly declare the ones you want to pass, which you can do so in the config).

          The config is also a lot simpler, and doesn’t force you to use visudo - which never made sense to me, visudo should’ve just generated the actual config, instead of checking it after the fact. Kinda like how grubby or grub2-mkconfig works. But no need for that complexity with doas.

          Eg, the most basic doas config could just have one line in the file: permit: wheel. Maybe have another line for programs you want to run without a password, like permit nopass dexter cmd pacman.

          • Technus@lemmy.zip
            link
            fedilink
            arrow-up
            13
            ·
            7 months ago

            Nice to see that Mastodon has the same problem as Twitter with people trying to use it for long-form blog posts for some godforsaken reason.

            • taladar@sh.itjust.works
              link
              fedilink
              arrow-up
              5
              ·
              7 months ago

              Makes sense considering people who moved from one micro-blogging service to another instead of giving up on the idea completely are probably the ones deeply committed to that flawed idea.

            • Regalia@lemmy.blahaj.zone
              link
              fedilink
              arrow-up
              2
              ·
              7 months ago

              Blame the Mastodon team, if you’re not running a fork, you have to go into the source and adjust the character limit manually.

              Nobody has to do it like this, Mastodon supports longer posts since other servers and clients support more, it’s seemingly just a choice from upstream.

          • UID_Zero
            link
            fedilink
            English
            arrow-up
            2
            ·
            7 months ago

            I admit, I’m not a big fan of putting more functionality into systemd (or just of systemd in general), but that is a well-reasoned argument for having sudo live in the init system.

    • million@lemmy.world
      link
      fedilink
      English
      arrow-up
      7
      ·
      edit-2
      7 months ago

      I read the original mastodon post by the developer of run0 and I am still don’t understand what the problem with SUID is.

      Whats an example of an attack that would work with sudo and doas (which also uses SUID) and not on run0?

        • ZeDoTelhado@lemmy.world
          link
          fedilink
          arrow-up
          2
          ·
          7 months ago

          Thanks for taking the time to explain. I was trying to get my head around on how this works but could not understand much of it. A lot of people here are very much against systemd in all senses, but this sounds like a better approach. Even if it not done as systemd, makes more sense than checking files and getting elevated privileges for a scope and use guardrails everywhere

  • dotslashme
    link
    fedilink
    English
    arrow-up
    69
    arrow-down
    10
    ·
    7 months ago

    Not that I’m opposed to a better sudo alternatives, but I find it rather ironic that one of the reason stated is the large attack surface, considering systemd is a massive attack surface already.

    • NekkoDroid@programming.dev
      link
      fedilink
      arrow-up
      30
      arrow-down
      10
      ·
      edit-2
      7 months ago

      This isn’t exactly a “new” attack surface, so removing the attack surface that sudo (and alternatives) is, is probably a net positive.

      • jkrtn@lemmy.ml
        link
        fedilink
        arrow-up
        10
        arrow-down
        2
        ·
        7 months ago

        That attack surface is not vanishing. It’s would be relocating the same attack surface to something that might have an xz library in memory.

        • NekkoDroid@programming.dev
          link
          fedilink
          arrow-up
          4
          arrow-down
          1
          ·
          7 months ago
          1. The attack surface is there either way, this is just functionality repackaged that existed already before (systemd-run, which is calling into PID1)
          2. all compression libraries (actually most libraries at this point) are dlopened on demand (which was planned even before the attack, which is speculated that the attack was accelerated in timeline because he was on a timer before the change was released)
  • onlinepersona@programming.dev
    link
    fedilink
    English
    arrow-up
    48
    arrow-down
    2
    ·
    7 months ago

    There’s a rewrite of sudo happening in rust, but he wants to throw out the SUID idea altogether?

    when invoked under the “run0” name (via a symlink) it behaves a lot like a sudo clone. But with one key difference: it’s not in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user’s UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY.

    That sounds like opening up the door to what windows is doing UAC and the wonderful vulnerability that the GOG Launcher had for privilege escalation.

    I’m not a security researcher, but giving arbitrary users the ability to tel PID 1 to run a binary of the user’s choosing is… probably not what Pottering is suggesting, but opens up to such vulnerabilities. And if it’s written in C/C++ my trust is further reduced.

    Anti Commercial-AI license

    • barsoap@lemm.ee
      link
      fedilink
      arrow-up
      6
      ·
      7 months ago

      Giving users access to PID1 running binaries, giving users access to the kernel running binaries as root, I don’t see much difference. SUID was notorious in the past for being leaky, it only ended when distros got serious about fencing use of it in, giving it only to programs actually needing it, making sure that they drop privilege properly, etc.

      If anything I’m in the PID1 camp because it’s more microkernely. But in any case broader userspace shouldn’t really care about the mechanism, only have an API to do it and that API being a bit in the file permissions is soooo 1960s.

    • ulkesh@beehaw.org
      link
      fedilink
      English
      arrow-up
      2
      arrow-down
      1
      ·
      7 months ago

      And if it’s written in C/C++ my trust is further reduced.

      Do you trust Linux? Because if so, have I got news for you.

      • shirro@aussie.zone
        link
        fedilink
        English
        arrow-up
        3
        ·
        7 months ago

        Wait until they hear the language used to implement OpenBSD. Imagine being one of the authors of seL4 encountering a member of the rust cult.

  • SuperSpruce@lemmy.zip
    link
    fedilink
    arrow-up
    54
    arrow-down
    8
    ·
    7 months ago

    I’m no Linux expert, but I’ve never had any problems with sudo, it just works. Shouldn’t systemd have higher priorities on their mind? This feels like change for the sake of change. And if this does happen, I sincerely hope that it just works, like sudo.

    • Kwdg@discuss.tchncs.de
      link
      fedilink
      arrow-up
      41
      arrow-down
      3
      ·
      7 months ago

      I think the article (or more Lennart Poertting post) explains it quite nicely. The problem with sudo is that the sudo binary itself has the ability to gane elevated privileges which is a potential attack surface

  • vsis@feddit.cl
    link
    fedilink
    English
    arrow-up
    46
    arrow-down
    1
    ·
    7 months ago

    Oh, it’s gonna use polkit. Sudo bloat is a grain of sand compared to polkit.

    Why people want to replace sudo with polkit? Visudo is no near as obscure as configuring polkit.

    I hope distro maintainers don’t follow this.

    • lengau@midwest.social
      link
      fedilink
      arrow-up
      14
      ·
      7 months ago

      …is pkexec not good enough already as a polkit based sudo replacement? Why would one need to systemd-ify that?

    • voxel@sopuli.xyz
      link
      fedilink
      arrow-up
      2
      ·
      7 months ago

      I just treat polkit as “set it and forget” kind of thing and leave it on defaults, I’d rather spend my time on something more important

    • john89@lemmy.ca
      link
      fedilink
      arrow-up
      2
      arrow-down
      2
      ·
      7 months ago

      First thing I do with any new desktop installation is disable polkit prompts.

      Fuck having to enter my password every time I want to do something.

      • caseyweederman@lemmy.ca
        link
        fedilink
        arrow-up
        1
        arrow-down
        1
        ·
        7 months ago

        Hey uh can I get your IP address real quick? I have a strong suspicion your philosophy extends to your network ports.

        • john89@lemmy.ca
          link
          fedilink
          arrow-up
          1
          arrow-down
          1
          ·
          edit-2
          7 months ago

          You’d be wrong about that.

          Edit: he just downvotes me instead of admitting he’s wrong about his assumption, lol.

  • nyan@sh.itjust.works
    link
    fedilink
    arrow-up
    52
    arrow-down
    8
    ·
    7 months ago

    sudo is already an optional component (yes, really—I don’t have it installed). Don’t want its attack surface? You can stick with su and its attack surface instead. Either is going to be smaller than systemd’s.

    systemd’s feature creep is only surpassed by that of emacs.

    • Revan343@lemmy.ca
      link
      fedilink
      arrow-up
      27
      arrow-down
      1
      ·
      7 months ago

      systemd’s feature creep is only surpassed by that of emacs.

      Tomorrow’s headline: emacs wants to expand to include a Sudo replacement

      • pingveno@lemmy.ml
        link
        fedilink
        English
        arrow-up
        10
        ·
        7 months ago

        Though a Rust clone of sudo that operates in the same way will still have the same problems.

      • nyan@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        arrow-down
        2
        ·
        7 months ago

        The problem is that those modules are packaged by the developers as opt-out rather than opt-in. It’s a variation on Microsoft’s old embrace-extend-extinguish playbook, only the “extinguish” part hasn’t worked so well because there are some stubborn distros whose needs don’t align with what systemd provides and have maintainers that go out of their way to provide alternatives.

        (By contrast, although we may joke about emacs, it’s the myriad of third-party extensions that cause it to just about be its own operating system—it doesn’t all ship with the core.)

    • fruitycoder@sh.itjust.works
      link
      fedilink
      arrow-up
      2
      ·
      7 months ago

      I’m not a fan of having root be able to actually login.

      Even more so in a true multiuser env where I would rather have privilege escalation be more granular (certain user/groups can esculate certain actions but not others, maybe even limit options of a cmd).

      • nyan@sh.itjust.works
        link
        fedilink
        arrow-up
        2
        ·
        7 months ago

        Granted, in a true multiuser environment with an admin who’s carefully tailoring /etc/sudoers to make sure everyone has the least possible privileges that will allow them to still do what they need, sudo is more secure. There’s no doubt of that.

        On a machine that has only one human user who’s also the admin, and retains the default sudo-with-user-passwords configuration, su vs sudo is pretty much a wash, security-wise. su requires a second password to get root access, but sudo times out and requires the password to be re-entered while a shell created by su can stay open indefinitely. Which is more easily broken will depend on other details of your situation.

        (If you’re running an incorrectly configured ssh server that allows direct root login with only password authentification, having a root password could contribute to problems, but the correct fix there is to reconfigure the ssh server not to do something so stupid. I hope there’s no distro that still ships that way out of the box.)

  • vanderbilt@lemmy.world
    link
    fedilink
    English
    arrow-up
    40
    arrow-down
    1
    ·
    7 months ago

    A lot (and I mean a lot) of criticism can be leveled at systemD. One of the upsides of it becoming popular is the standardization of much of things from the developers’ perspective. It’s easier to target multiple distros when you can rely on systemD’s single implementation of the feature. Over the next decade, I forsee systemD eating more and more of the userspace, until you are only left with managing the differences between DEs and which display server they are using. We’re already headed towards immutable base systems with apps shipping with their own dependencies, which we reduce the differences between distros even further.

    • baru@lemmy.world
      link
      fedilink
      arrow-up
      15
      ·
      7 months ago

      until you are only left with managing the differences between DEs

      Maybe they’ll add a DE as well?

      Just kidding!

      • vanderbilt@lemmy.world
        link
        fedilink
        English
        arrow-up
        13
        ·
        7 months ago

        Don’t give them ideas 😂

        If Canonical and RedHat weren’t backing different horses (Snap vs Flatpak), I could see the app containerization system coming under systemD as well fairly soon. The Cosmic DE project uses functionality from systemD to overlay changes onto the system that are reversible, so that alpha versions of Cosmic can be tested without permanently changing the base system. Imagine apps shipping on whatever container runtime, and dynamically overlaying system-level changes as needed for things that tap into the host system via systemd-sysext.

  • nifoc@lemm.ee
    link
    fedilink
    English
    arrow-up
    51
    arrow-down
    14
    ·
    7 months ago

    This is great. Not having the attack surface of sudo (and not even being a SUID binary) certainly are great additions.

    And I hope people realize that systemd is not one large thing, but a (large) collection of tools.

    • DefederateLemmyMl@feddit.nl
      link
      fedilink
      English
      arrow-up
      37
      arrow-down
      6
      ·
      7 months ago

      The attack surface will be a systemd daemon running with UID=0 instead, because how else are you going to hand out root privileges?

      So it doesn’t really change anything to the attack surface, it just moves it to a different location.

      • Kwdg@discuss.tchncs.de
        link
        fedilink
        arrow-up
        4
        arrow-down
        5
        ·
        7 months ago

        That already exists. systemd-run is already available today. So the attack surface would be smaller

        • DefederateLemmyMl@feddit.nl
          link
          fedilink
          English
          arrow-up
          7
          arrow-down
          1
          ·
          7 months ago

          Not really, because you’re now going to make it do more, i.e. incorporate the functionality of sudo and expose it to user input. So unless you can prove that the newly written code is somehow inherently more secure than sudo’s existing code, the attack surface is exactly the same.

    • MonkderDritte@feddit.de
      link
      fedilink
      arrow-up
      23
      arrow-down
      5
      ·
      edit-2
      7 months ago

      that systemd is not one large thing, but a (large) collection of tools.

      Who don’t work without Systemd. And Systemd can’t coexist with tools in the same repo doing the same job in a portable way.

      I think Chimera was it (?) which tried to have Systemd and Runit and others in the same repo. With lots of wrappers and shims. Not because of Runit & co.

      • lemmyreader@lemmy.ml
        link
        fedilink
        English
        arrow-up
        4
        ·
        7 months ago

        Right. That reminds of the time I was visiting a friend who had broken his Linux computer (No, not “apt-get remove --purge systemd” but they did something slightly similar). When I booted from a live Linux, used chroot and wanted to use configure networking : FAIL because systemd was … not running. As he had no Internet because of his broken machine this caused some delays in fixing this but we got the job done eventually.

    • lemmyreader@lemmy.ml
      link
      fedilink
      English
      arrow-up
      14
      arrow-down
      10
      ·
      edit-2
      7 months ago

      This is great. Not having the attack surface of sudo (and not even being a SUID binary) certainly are great additions.

      And I hope people realize that systemd is not one large thing, but a (large) collection of tools.

      XZ-utils rings a bell ? It was among others Debian wanting to pull in part of a systemd tool into openssh and that almost turned into a world wide disaster :(

      • boredsquirrel@slrpnk.net
        link
        fedilink
        arrow-up
        15
        arrow-down
        2
        ·
        7 months ago

        I didnt understand that sentence. Is that what you meant?

        Among other things, Debian wanted to integrate a part of the systemd tools into openssh, which almost led to a worldwide catastrophe

        xz is not part of systemd or openssh afaik.

        • lemmyreader@lemmy.ml
          link
          fedilink
          English
          arrow-up
          14
          arrow-down
          4
          ·
          7 months ago

          You didn’t follow the XZ-utils story ? The malicious actor worked for years on that XZ backdoor that targeted the fact that some Linux distributions were modifying their openssh package to enable systemd notifications.

          • boredsquirrel@slrpnk.net
            link
            fedilink
            arrow-up
            7
            arrow-down
            7
            ·
            7 months ago

            Ok true, it was a systemd dependent issue. But it only makes sense to have those notifications. The problem is dependency on small hardly maintained products, which systemd will improve by centralizing it.

            • Macros@feddit.de
              link
              fedilink
              arrow-up
              4
              arrow-down
              1
              ·
              7 months ago

              And where do maintainers for the new parts of systemd come from? The larger systemd grows the more parts of it will be neglected. Also in regard to people checking commits, opening up doors for exploits like the one in xz.

            • lemmyreader@lemmy.ml
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              7 months ago

              But it only makes sense to have those notifications.

              Maybe in your mind it makes sense. Going for ease of use rather than security is not something that OpenBSD would quickly do. If you read some more about what “jwz” has to say about all the screensaver bugs in Linux, like here : https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition and realize what a mess that Linux maintainers are making again and again, and then have a look at Debian and their packaging of xscreensaver. Guess what ? Debian added some systemd thingie to xscreensaver. 🤯

              I like Debian since a long time and I use it. But the tinkering of Debian package maintainers and always wanting to do things the Debian way is not something I am always very pleased with. Remember the OpenSSL Debian fiasco ? That shows a problem with Debian which may still exist. Too many packages, not enough maintainers with enough spare time, and no coherent team work of a security team.

              • boredsquirrel@slrpnk.net
                link
                fedilink
                arrow-up
                1
                ·
                7 months ago

                You are talking about Debian holding back random packages for stability. This is of course not very cool but it needs to be tested.

                I am very much in favor of isolate app environments controlled by upstream devs, containerized and with a permission system. The system is made by the distro, and can be stable and very tested, and the apps are simply isolated and made by upstream.

                There is no xscreensaver on Wayland and I think this will not come back?

    • lengau@midwest.social
      link
      fedilink
      arrow-up
      2
      ·
      7 months ago

      Kinda feels like writing a script that implements the sudo CLI but calls pkexec would be an easier way to do it. Given that so many systems already come with both sudo and pkexec, do we really need yet another option?

      • chameleon@kbin.social
        link
        fedilink
        arrow-up
        3
        ·
        7 months ago

        The point of this is to implement some form of privilege escalation without the SUID mechanism. sudo, pkexec and doas are all SUID.

    • DigitalDilemma@lemmy.ml
      link
      fedilink
      arrow-up
      2
      ·
      7 months ago

      I’ve had to scroll down eight pages to find a post that seems to actually address the good points raised in the article.

  • gandalf_der_12te@discuss.tchncs.de
    link
    fedilink
    arrow-up
    38
    arrow-down
    2
    ·
    7 months ago

    I honestly started out not liking systemd at all, mostly due to the reports that it did waaay to much, but nowadays, I like the concept.

    It is basically officially moving daemon management from a script-based approach to a table/database-based approach. That improves static analyzability, therefore increasing clarity, and probably even performance.

    I agree that we should abandon scripts and move towards declarative software management, and abandoning sudo for a more declarative system seems like a good step to me.

  • Jears@social.jears.at
    link
    fedilink
    arrow-up
    36
    arrow-down
    1
    ·
    7 months ago

    So I don’t even use systemd myself I run OpenRC. Yet honestly I find the idea quite intriguing, having the service manager (PID 1) invoke the command seems like a cool idea to me.

    It’s not really a sudo alternative as much as it is another way of doing something similar.