49 ms·

Run0, a systemd based alternative to sudo, announced

• CoolCold 2y ago
  Uses polkit. run0, which behaves like sudo, but works entirely differently and is not SUID. Run0 asks the services manager to create a shell or command under the target user’s ID, creating a new PTY, sending data back and forth from the originating TTY and the new PTY.
  • segasaturn 2y ago
    How hard would it be to create a program to send a signal to polkit "impersonating" run0 and obtains a root shell? :)
    • gh02t 2y ago
      Is that even a problem? Any program can shell out to sudo, hence why you shouldn't set NOPASSWD in sudoers. Polkit takes in a request on an unprivileged interface, that request is evaluated in privileged code against the set of privilege rules, and then passed the proper capabilities if the rules allow. This includes a mechanism where it can, if desired, prompt a user to enter a password etc to prevent a rogue program silently acquiring root. But even in the worst case, the rogue program is not going to acquire any capabilities that you would not otherwise have as with sudo, and the breakpoint between privileged and unprivileged code is (in theory) more tightly defined and controlled.
    • YtvwlD 2y ago
      You'd need to be root already, so hard.
    • intelfx 2y ago
      run0 does not send any signal to polkit, systemd does.
• TacticalCoder 2y ago
  > Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, ... Of course. The solution to every Linux "problem" is, of fucking course, to have the PID1 spread is tentacles to yet more part of Linux. Every single problem can be solved by giving yet more power to PID1... Except the problem of PID1 having too much power.
• wkat4242 2y ago
  I'm really starting to hate the sub-community in Linux that tries to constantly change it. I don't want to learn a new network config alternative with every update (Ubuntu changed its net config tool again with 24.04). I don't want an immutable os. I don't want to learn to write new config files. I just want to do what I've been doing but with new packages. If there's a problem with something, just fix it. Don't throw out the whole thing. I moved to FreeBSD and am happy for its reluctance to change. If there is any, it's usually offering something genuinely new to me as a feature and to boot I only need to learn about it if I need it. Hardware support is much lower but it's worth it IMO. I had the same irritation with macOS. Every release breaking something essential that was part of my workflow and i didn't want to change. Eventually I did change but away from Apple. I don't want to change to LennartOS either.
  • hasselhoftd 2y ago
    Agreed. I've taken to treating my linux installs like I used to treat Windows: no internet access expect application specific. For example, I run a Visionfive 2 OpenBSD install with squid, everything else has to go through that.
    • cyberpunk 2y ago
      Curious why squid and not pf?
      • Khaine 2y ago
        squid is a http(s) proxy and pf is a firewall. They do not do the same thing.
        • cyberpunk 2y ago
          I assumed it wasn’t doing tls interception as simply using it to allow/disallow internet traffic from various internal hosts — pf works for that also. Relayd also does a bunch of similar things and is closely integrated with pf too..
• bananskalhalk 2y ago
  I was really hoping the next sudo replacement would borrow heavily on root as role[0] (if not being root as role). Feels like a missed opportunity to not use capabilities. [0]: https://www.sciencedirect.com/science/article/pii/S0167404822003753 https://www.sciencedirect.com/science/article/pii/S016740482...
  • bandrami 2y ago
    Capabilities aren't guaranteed to be present, and in a lot of high-security situations aren't available (though obviously you could say that about sudo too)
    • bananskalhalk 2y ago
      Sounds exciting and might be obvious, but where will I find systemd and not capabilities?
      • bandrami 2y ago
        Containers
• viraptor 2y ago
  That looks pretty good. I'm glad that the plan is to make this more typing friendly - systemd-run is not good enough for daily usage.
• pmlnr 2y ago
  > The developer talks about the weaknesses of sudo, and how it has a large possible attack surface Poettering's hypocrisy is painful.
  • mort96 2y ago
    Is it? Does systemd's sudo replacement also have a lot of complex code running as root in a suid binary? Because that's what he's complaining about
    • jpollock 2y ago
      People blame systemd for making the liblzma problem larger than it should have been. https://marc.info/?l=openbsd-misc&m=171227941117852&w=2 https://marc.info/?l=openbsd-misc&m=171227941117852&w=2 "Liblzma ends up dynamically linked to sshd because of a systemd-related extension added by many Linux packagers that pulls in liblzma as an unrelated dependency." https://news.ycombinator.com/item?id=39866076 https://news.ycombinator.com/item?id=39866076 "openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma."
      • deleted 2y ago
        [deleted]
      • deng 2y ago
        So that's your best shot against systemd? - Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library. - libsystemd depends on libzlma - libzlma depends on xz And therefore, systemd is insecure? And what does this have to do with the fact that SUID is a terrible idea that needs to go?
        • lmm 2y ago
          > - Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library. Why was that? Would that "trivial" approach have broken the next time systemd made one of their incompatible interface changes, perhaps? Was using libsystemd the kind of thing the systemd maintainers recommended? > And therefore, systemd is insecure? Systems with systemd had a vulnerability that systems without systemd did not. So it certainly seems like systemd-the-system (not necessarily systemd-the-unix-process) is bad for security.
• adontz 2y ago
  here's a new tool in systemd, called "run0". Or actually, it's not a new tool, it's actually the long existing tool "systemd-run", but when invoked under the "run0" name (via a symlink) it behaves a lot like a sudo clone.
• hulitu 2y ago
  [flagged]
• creshal 2y ago
  But they already ship pkexec together with systemd anyway via polkit, why are they again reinventing a wheel they already reinvented? Unit files are a neat concept I don't want to miss again, but everything else done by Lennart seems to be an inceasingly stupid mistake born from hubris.
  • roenxi 2y ago
    AFAIK privileges are an area that has an easy problem statement ("execute this command with that capability") and is fiendishly difficult to execute in practice. `sudo` alone has weird bits to set in the filesystem, magic users and all sorts of unhelpful implications - and it doesn't even lead to any particular security for single-user systems. Same-user code is a scary enough place to be running untrusted code. Those sort of problems sound like the sort that get a lot of attempts which run into the complexity wall and halt. I think Amazon has one of the best implementations of a privilege system I've used and it is horrible.
  • deng 2y ago
    Because pkexec has the same problems as sudo: it's a SUID binary. As Lennart says, the goal is to eventually get rid of SUID binaries altogether, as they are an inherent security risk. Replacing sudo with pkexec would not change much. In fact, pkexec has had its fair share of local root exploits over the past few years.
  • eternityforest 2y ago
    This seems like it won't break anything except really exotic scripts, I think it will probably be a good thing for at least the main target audience of systemd, id imagine it might somehow suck for others though.
    • aragilar 2y ago
      Uh, depending on exactly how it's implemented, it could break a lot of things. If all you are using sudo on is a personal (i.e. single user) laptop/desktop to install packages, this (along with other things like pkexec or doas) would seem to present no issues (and personally, from what I can see, I'd be happy to run `run0` on my personal systems!), but sudo does significantly more than that, as is called out by the systemd devs in the linked post https://mastodon.social/@pid_eins/112353324518585654 https://mastodon.social/@pid_eins/112353324518585654 sudo supports not just LDAP (for multi-user systems), but include various levels of logging (including logging stdin and stdout of commands), apparmor and selinux profiles, the BSD and linux audit subsystem and more in a simple, easy to read and edit config format (this is just me reading from the `sudoers(5)` man page). Whereas it seems `run0` won't have a `sudoers` file, but will instead be configurable (implicitly) via polkit, which uses JS to write policies (which I'd view as a much harder and error-prone system than the current `sudoers` format). It's not clear to me how much of sudo is tied to SUID vs. having a separate daemon (i.e. how much would have to be ditched vs. how much could be mapped over). I do feel this is systemd moving away from traditional multi-user unix systems to being a single-user system (targeting the laptop/desktop case, or where sys-admins are the only users of the system, and it's basically a container host).
• andrewstuart 2y ago
  “Systemd” and “expand” used in the same sentence….. all the systemd haters will be triggered like it’s the national rifle association shooting carnival. In many ways systemd has actually become the operating system. It’s so pervasive that it certainly is more deserving of naming rights than gnu. “Systemd/Linux” makes more sense than “gnu/Linux”
  • blackhaz 2y ago
    Mark my words, you won't be able to see the kernel anywhere in there soon!
  • timetraveller26 2y ago
    "Systemd wants to expand to include a replacement of the Linux kernel" headline coming soon
    • Spivak 2y ago
      People have been memeing this for a long time but if you know anything about the project you would know that one of systemd's explicit goals is to use the full capabilities of the Linux kernel to hell if it's not portable to other kernels.
• kristjank 2y ago
  I am looking forward to the day systemd will implement everything a typical Linux system needs. No more systems greater than the sum of their parts, just a Half-Life 2-style Combine of Microsoft sponsored Poetteringware, running a monolythic system on top of a monolythic kernel, until systemd rewrites the Linux kernel as well. The future is bright! \s Seriously though, this seems to be a decent replacement for sudo if it works as seamlessly as it's described in the article. I still prefer the doas line of approach that simplifies the tool as much as possible, but I see the value of having such an important tool integrated into the existing system tooling, especially if it already includes everything but the kitchen sink.
• rahen 2y ago
  I thought doas had solved this already.
  • progval 2y ago
    doas uses SUID
    • bandrami 2y ago
      It either has to be SUID or it has be a daemon running as root (or with enough caps to make the difference not matter). Adding a needlessly verbose configuration ecosystem doesn't change that. I imagine there's going to be some cool stuff this can do with homed and userctl, but it's not like the fundamental problem of "this program can grant root privileges" can ever go away.
      • dale_glass 2y ago
        The problem is not "this program can grant root privileges", it's that the setuid bit sucks. Linux processes inherit a lot of state from the parent which means it's absolute hell to make a secure setuid binary. And at any time the Linux kernel can add a new feature which will be inherited by a child process, but that the process can't defend against because it wasn't even a thing when the code was written. Running a binary at all also goes through a complex set of initialization steps a lot of programmers barely know exist, let alone are able to understand fully.
        • bandrami 2y ago
          Sure, but your choices are running an on-demand binary suid root, or running a persistent daemon as root. Both have problems, but if you're going to switch users to root you have to do one of them.
          • dale_glass 2y ago
            The tool doesn't try to do away with root, it tries to do await with the setuid bit. Meaning, "running a persistent daemon as root" is the intentional solution, and presented as the significantly better option for good security.
• StimDeck 2y ago
  Just a reminder that there are plenty of systemd-less distros available. Also a reminder that those distros would have been safe from the nearly-solar-winds-level backdooring of Linux distros from XZ utils.
  • Jonnax 2y ago
    That backdoor was never pushed out of the testing branches for distros.
    • StimDeck 2y ago
      Not sure of the relevance of this comment, can you elaborate? Were you the one that caught it? Our balls were inches from the bandsaw. Systemd made it possible to compromise SSH through an unrelated, single-maintainer lib that wasn’t even a dependency. Edit: never mind, I see you are a systemd crusader.
    • wpm 2y ago
      Oh well I guess it didn't matter then.
    • Arnavion 2y ago
      It was in OpenSUSE Tumbleweed for a few days actually (RPM-based + rolling release + did the sshd patch). I was affected by it and it was fun watching the reliable ~100ms difference in `time /usr/sbin/sshd -h` with and without `TERM=foo`
  • nialv7 2y ago
    Can you even hear what you are saying? Don't you find it ridiculous to blame the XZ backdoor on systemd, instead of the actual hacker? Even if systemd did not exist, the hacker would have just picked something else to infiltrate.
    • bitwize 2y ago
      Of course, the actual hacker was to blame, but systemd was implicated. The fact that the attacker was willing to settle for compromising just Debian and Red Hat systems indicated that they perceived the path from xz to libsystemd was the easiest way to effect the backdoor and that doing it any other way would have been too much work for marginally little gain (Red Hat and Debian systems being so common).
• Iridescent_ 2y ago
  Wasn't the recent liblzma attack already exploiting the fact that systemd has its hands in pretty much everything? Wouldn't this expand further the attack surface of systemd and the systems that connect with it?
  • viraptor 2y ago
    That's not a great summary of lzma. It was systems adding custom patch to ssh which used a systemd-related library which it didn't really need in the first place. It's a stack of issues that don't have much to do with systemd itself really. But re. expanding the attack surface - unlikely. Systemd's primary purpose is to start processes with the right environment / permissions. systemd-run/run0 basically give you the tool to invoke that functionality with a terminal attached to it. That's smaller scope of extra code than sudo/doas deal with.
    • metta2uall 2y ago
      Isn't it a fault of systemd that libsystemd had a dependency on libxz? (because it implements too many things). It should have been possible to add the notification functionality using a tiny libsystemd-notify.
      • viraptor 2y ago
        It's not a fault. They needed xz for some functionality and didn't want to split that library into multiple pieces. That's just a choice. But either way, you could always do notification in a few lines yourself (probably as many as you needed to link that library in the first place). I've done multiple 3-line "implementations" in Python and Ruby in the past and never linked it for example.
  • exe34 2y ago
    I'm surprised he hasn't started writing his own kernel by now.
    • jbverschoor 2y ago
• rurban 2y ago
  For one, a good effort by Lennart.
• mise_en_place 2y ago
  sudo and su made sense when it was a multiuser time sharing system. You needed clear boundaries between each users of the system, and permission bits. If I’m running on my workstation or desktop just let me run the damn thing. I don’t need an unprivileged user. On TempleOS you can modify the running system in ways you can’t on Linux.
  • foul 2y ago
    Plan9 propaganda in the wild
• gjjydfhgd 2y ago
  [flagged]
• constantcrying 2y ago
  Why do they have to do this? This is really, really stupid. My issue isn't even that someone tries to replace sudo. That may or may not be a completely fine thing to do, depending on the state of sudo and what improvements can be made. But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none. This is a completely insane way to develop software, instead of creating a new piece of software in a separate project they will force all their projects simultaneously onto all their users for absolutely no reason. I am very glad to have jumped ship from systemd. It is particularly bad software created by a team of people who engage in very bad practices and a totally unhealthy view of software in general.
  • dmm 2y ago
    > they will force all their projects simultaneously onto all their users for absolutely no reason. That's just not true. Just because a system uses systemd the init system doesn't mean the it is forced to use the other components.
    • constantcrying 2y ago
      The single beat reason for doing this is to get a coherent complete system. This is what every other person here says. You can not try to create a large coherent system and then tell people they shouldn't use that particular part. That is totally disingenuous. Systemd is DESIGNED to be an all or nothing deal.
      • growse 2y ago
        > Systemd is DESIGNED to be an all or nothing deal. ^[Citation needed]
        • constantcrying 2y ago
          Again and again people in this thread have told me that the great thing about systems is that it delivers integrated tools.
• KaiserPro 2y ago
  Thats fine, and lord knows we probably need a replacement to sudo. However, sudo needs to be user friendly and fail safe with decent information as to why its failed. Something that service files historically didn't do. But, the way it's supported also needs to change, it almost certainly needs to be decoupled from systemd's release cycle. I hope that we have all learnt from early systemd, and that we all won't take a "lets piss on each other's chips" approach. I'm too old you you lot to start flame warring over stuff you'll never actually fucking use.
  • mynameisnoone 2y ago
    doas exists but isn't universally available but already solves this problem. sudo has too many features and permits excessive configuration, but it also has the convenience of ubiquity. Inventing a third thing tied to systemd is absurd and unnecessary.
• kbar13 2y ago
  systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run globally to the front of the filename". it's provided an extensible platform with which higher level orchestration frameworks like ansible / ignition can easily templatize services or other system configuration. since the beginning of systemd people have moaned about how complex it is and how we're reinventing the wheel. yet time and time again the people actually working on the project show that the solution they've come up with is the result of the problem they're facing on a daily basis. it's quite annoying that the armchair linux experts complain about how "lol systemd is so stupid for reinventing the wheel, give me my shell scripts back", maybe think about whether or not you have a legitimate issue not being addressed by the solution proposed or if you are just getting rage baited by a headline.
  • dcow 2y ago
    I love systemd.
    • andrewstuart 2y ago
      Me too. The best thing about Linux.
      • jbverschoor 2y ago
        It's a re-implementation of Apple's launchd. I've always liked it though
        • bryanlarsen 2y ago
          A much improved version of launchd, yes.
        • freedomben 2y ago
• frafra 2y ago
  This is not new functionality: "There’s a new tool in systemd, called “run0”. Or actually, it’s not a new tool, it’s actually the long-existing tool “systemd-run”, but when invoked under the “run0” name (via a symlink)". systemd-run is very useful to run tasks with specific cgroups settings, or at a specific time. It asks for password whenever needed.
• mehdix 2y ago
  Lennart's toots suggest they are replacing a complex SUID binary with an already existing component (systemd-run) with better workflow (service manager handling the elevated context), which sounds like a sane move to me.
• gpderetta 2y ago
  Does systemd read email yet?
• my_choice 2y ago
  [flagged]
• katmai 2y ago
  [flagged]
• ezoe 2y ago
  I wonder what other existing programs Will Systemd attempt to replace in the future. My bet is /bin/sh, maybe they went further to replace the entire POSIX utilities.
  • anthk 2y ago
    Guix will reimplement POSIX utils and extras with tools written in Gule.
    • smegger001 2y ago
      Please say this is a joke
      • anthk 2y ago
        https://nlnet.nl/project/Gash/ https://nlnet.nl/project/Gash/ It wouldn't be a bad idea. Also, Guile's JIT could be interesting there. Also, a shell with a live REPL instead of failing on errors can be pretty interesting.
        • zarzavat 2y ago
          “gash” oh my, what a name. Do you think they know?
  • quectophoton 2y ago
    filesystemd, replacing ext4/btrfs/etc. It will come with `filectl` for all your file operations, so you will no longer need `cd`, `pwd`, `touch`, `rm`, `mkdir`, `cat`, `grep`, `find`, etc. Instead you do everything through `filectl` commands. This will deprecate many commands from GNU coreutils, which is a good thing because replacing things is always good. Then, since programs are just files, and filesystem will be part of systemd, any program you want to use will obviously have to go through systemd as well, meaning they will need to be a service unit of type `oneshot`, because this way we keep everything well integrated together. Don't worry tho, you only write the unit files once and they work forever. The only thing you need to remember is that, instead of `cargo build` you'll need to use `filectl exec -u cargo build` (`filectl exec -u` is only 3 words, so you don't have the right to ever complain about this tiny little change). Anyone who doesn't like these changes is stuck in the past.
• sys_64738 2y ago
  How long before humans are systemd compatible?
• segasaturn 2y ago
  This is very interesting, can somebody explain what this is and how it's different from executing through sudo? The LWN post links back to Lennart's Mastodon which in turn is a big pile of toots (ugh) in the wrong order
• immibis 2y ago
  This will be great. We can finally deprecate sudo on systemd systems. Then we should be able to deprecate PAM, setuid bit, etc.
  • yjftsjthsd-h 2y ago
    I can see creating a system with zero setuid files, but I don't think this reduces PAM use, does it?
    • eichin 2y ago
      Not setuid generically, but `sudo` itself has a bunch of pam support/dependency.
      • yjftsjthsd-h 2y ago
        I would expect sudo to also touch pam a lot, but AIUI systemd also uses pam through polkit for its ~native permission system - https://serverfault.com/questions/841306/authentication-is-required-to-manage-system-services-or-units https://serverfault.com/questions/841306/authentication-is-r...
  • cedws 2y ago
    I wonder, are there any distros already with a nosuid root?
  • Retr0id 2y ago
    Is removing setuid actually a win? I know it presents a security risk, but it feels like we're not actually removing that attack surface, just moving it around.
    • NekkoDroid 2y ago
      Well... that "attack surface" isn't new, its mostly just repackaging systemd-run, which is just used to tell PID1 to launch a new process. So in total the attack surface would be reduced by removing sudo.
• kevincox 2y ago
  > One could say, "run0" is closer to behaviour of "ssh" than to "sudo", in many ways. This is an interesting offhand comment. You could implement a very similar tool by SSHing to localhost.
  • __s 2y ago
    Indeed, there was a blog by a redhat engineer doing that: https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket
  • Arnavion 2y ago
    Technically `sudo -u` can switch to any user on the system while only a limited few would be allowed as ssh targets. Even root might not be allowed as an ssh target if `PermitRootLogin` is set to `no`, which I do on all my systems.
    • pmontra 2y ago
      I do use that a lot sudo -H -u user bash after I ssh into a server with my own account. That other user might even be a no login account.
      • noinsight 2y ago
        You can just use `-i` instead of `bash`. (This method indeed requires a shell configured, your method is needed with nologin.)
    • fsckboy 2y ago
      >Even root might not be allowed as an ssh target if `PermitRootLogin` is set to `no`, which I do on all my systems. would something like PermitRootLogin=localhost punch an enormous hole in your intricate opsec?
      • jimbobthrowawy 2y ago
        I've set up tor on some machines to forward ssh as a hidden service for an easy to configure way to get past NAT before. That shows up as a login from localhost. (could be configured differently, with some extra work) There's so ways to configure access to a system, each with footguns I'm surely unaware of.
• CuriousCosmic 2y ago
  [flagged]
  • IntelMiner 2y ago
    You're always welcome to write an alternative if you don't think systemd's direction is correct. Frankly with the number of detractors you could likely form a much larger team to "do it properly" instead! Love or hate Pottering and his team, they're at least writing code instead of postulating on internet forums. systemd's adoption and popularity among many is proof of that
    • ranger_danger 2y ago
      > instead of postulating on internet forums Love or hate internet discussion, you're always welcome to not participate in it.
      • IntelMiner 2y ago
        To your point. Lennart instead of participating, just writes code? :)
    • CuriousCosmic 2y ago
      > You're always welcome to write an alternative if you don't think systemd's direction is correct. They actually exist. Namely OpenRC and s6 as the main competitors to the core systemd functionality (init). There exist other alternative projects for the other components of systemd as well. My complaint is that they are adding another tool that depends on their core software in an attempt to replace a portable, well established tool in a non-drop-in way. This is a consistent pattern with systemd that feels very embrace-extend-extinguish-y and it does nothing but increase the cost involved in keeping code portable between different platforms.
  • ranger_danger 2y ago
    > it requires a ton of systemd infra to use I understand your frustration, but is it really fair to criticize a systemd feature for requiring systemd itself?
• fn-mote 2y ago
  Overall, this seems great. However... > [...] by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges ?!! ouch ... seems orthogonal to the actual important parts. Disclaimer: I didn't try it.
  • NekkoDroid 2y ago
    I tried it a bit ago (when it was still called uid0, pre-release), I also wasn't a fan of the tinting. I like the intent behind it, but some terminals already tint the header color when running sudo, I haven't tested if its done specifically for sudo or if its in a more generic way that could handle this as well.
    • Karellen 2y ago
      > I also wasn't a fan of the tinting. From the linked mastodon thread: > For example, by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges. That is supposed to act as a friendly reminder that you haven't given up the privileges yet, and marks the output of all commands that ran with privileges appropriately. (If you don't like this, you can easily turn it off via the --background= switch). (emphasis mine)
      • gh02t 2y ago
        It was a bit unclear to me from the thread, is there a persistent configuration option for this? I like the idea of tinting the terminal, but I also want to be able to turn it off with a global config option rather than having to type out a --background flag every invocation.
        • zamadatix 2y ago
          Aliasing the command as the command + your default arguments is the easiest general solution to this kind of problem. I'm not sure if there is a "systemd way" to permanently set it though.
• akagusu 2y ago
  Piece by piece, Red Hat is taking over the Linux ecosystem.
  • cozzyd 2y ago
    Ironically enough, Lennart now apparently works for Microsoft. (though to be clear, I like systemd and I think Lennart is a very good engineer).
    • oceanplexian 2y ago
      That’s a great fit for him since systemd appears to lift their monolithic design practices and force them on the Linux community.
  • izacus 2y ago
    Well, they're the only ones actually funding development of the ecosystem, aren't they? The rest just do a lot of opinoning and complaining and not that much of developing.
    • superkuh 2y ago
      The implicit premise of this comment is that linux is broken and needs to be changed. It isn't. The changes are not inherently good. Development is not inherently good. Just look at Gtk3 from 2014 to 2024. It was far more functional in 2014 (re: keyboard input) and now that has been removed because "progress".
      • throwaway11460 2y ago
        Nobody needs to adopt the changes. Everybody did because it's better than the alternatives. There are still systemd-less distros if you like it.
        • superkuh 2y ago
          My issue is not with systemd. My issue is with the argument that all development is good. In this example I am pointing out how Gtk3 has suffered from development attention from GNOME over the last decade and became worse. Maybe run0 is worse than sudo. Maybe not. I have no personal experience on that topic and I doubt anyone here does.
• segasaturn 2y ago
  I asked this in a thread about this from last night and didn't get a reply. For context, the way "run0" works is to apparently send a signal to polkit that requests a command under the root user's ID and permissions, thereby getting a privileged shell without SUID: > How hard would it be to create a program to send a signal to polkit "impersonating" run0 and obtain a root shell without entering a password? Anybody know how this is being authenticated?
  • ongy 2y ago
    Without looking at the he specific implementation There should be a service running as uid=0 that exposes an unprivileged API. This service then takes the RPC and does authorization with polkit. I.e. the unprivileged part doesn't talk to polkit directly. But a privileged part uses polkit instead of a custom sudoers style config.
  • thayne 2y ago
    I would assume the authentication happens in polkit, so a fake client would only be able to run a command if it had the necessary credentials.
• resuresu 2y ago
  [dead]
• StayTrue 2y ago
  Perhaps the nomenclature should be updated from GNU/Linux to GNU/systemd/Linux.
  • phone8675309 2y ago
    Until systemd consumes the kernel and then it will be GNU/systemd
    • CamouflagedKiwi 2y ago
      Or it consumes every other part of the GNU runtime and it becomes systemd/linux
      • Zuiii 2y ago
        At it's growth rate, it'll be just systemd. I'm only half joking unfortunately.
        • anticensor 2y ago
          or, Système D OS
    • bitwize 2y ago
      https://www.tumblr.com/wizardofbits/96856361060/rethinking-the-primacy-of-linux-in-a-linux-system https://www.tumblr.com/wizardofbits/96856361060/rethinking-t... Waiting for this to no longer be fake.
• abridgett 2y ago
  I'm not sure it can replace non-trivial setups - sudo/doas looks set to stay. e.g when you need to restrict a set of users to run only certain applications with certain other users. sudo can do this (even if the config format can be painful).
  • cozzyd 2y ago
    sure but very few people (relatively) are doing stuff like that?
  • lupire 2y ago
    What's the goal? If the host is to get most scenarios off sudo, exceptions aren't a problem. If the goal is to delete sudo, exceptions matter, and migrating what is migratable will clarify what the remaining requirements are.
  • stop50 2y ago
    Thats why i moved every sudoers rule to ldap. Much nicer to configure and no need for files with the same content on multiple servers. New users are added and removed fast and i can check the rule on any server.
  • agwa 2y ago
    Good news! run0 will use polkit[1], which uses JavaScript for its rules[2], so there's no limit to how complex your rules can get! On the other hand, maybe adding a JavaScript interpreter to Linux's trusted computing base isn't good news... [1] https://mastodon.social/@pid_eins/112353420303876549 https://mastodon.social/@pid_eins/112353420303876549 [2] https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html https://www.freedesktop.org/software/polkit/docs/latest/polk...
    • akira2501 2y ago
      If the lesson of xz was "reduce supply chain attack surface" then the freedesktop people clearly haven't received it yet.
      • 2y ago
• westmeal 2y ago
  what else is systemd going to eat :/
  • atoav 2y ago
    It would be really funny if systemd tried to replace pulseaudio.
    • Narishma 2y ago
      pulseaudio is already in the process of being replaced by pipewire.
      • atoav 2y ago
        Jup and that is good. Finally sending audio to multiple devices isn't a pain anymore.
    • figomore 2y ago
      Pulseaudio was created by Lennart Poettering.
      • atoav 2y ago
        Hence why it would be funny.
• withinboredom 2y ago
  I don't understand the point of creating an entirely new shell inheriting almost nothing. Seems like that would cause a lot of issues (i.e., sudo make install)
  • Arnavion 2y ago
    That's how sudo already works on most (all?) distros. Eg Debian 12 has: Defaults env_reset ... which will clear almost everything that `make install` would've used. OpenSUSE TW has: Defaults always_set_home Defaults env_reset Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE" ... which is a lot more, but will still clear whatever `make install` would've used. Anything you need to give to `make install` should be given explicitly, like `sudo make INSTALL_ROOT=$INSTALL_ROOT install` or whatever.
    • gcbirzan 2y ago
      If you're using autoconf/automake, you don't need to do that.
• throw0101b 2y ago
  First comment at the LWN: > […] I think calling the flags "setuid" (as lwn appears to prefer?) just blurs things, since that's the name of a syscall (setuid()), which does something related, but is not actually involved in the concept that the inode SUID flag is about. > Hence, I am a bit confused what that comment here is supposed to achieve? It just creates confusion? > Lennart * https://lwn.net/Articles/971747/ https://lwn.net/Articles/971747/ Reply by corbet: > Lennart, the purpose was to be sure that readers knew what the term meant in the quote, nothing more. Never change, Lennart, never change…
  • mzs 2y ago
    the right person to replace sudo, not: https://github.com/systemd/systemd/issues/6237 https://github.com/systemd/systemd/issues/6237 PS: https://pwnies.com/systemd-bugs/ https://pwnies.com/systemd-bugs/ edit, this one went on for more than a year: https://github.com/systemd/systemd/issues/6632 https://github.com/systemd/systemd/issues/6632
• dang 2y ago
  Url changed from https://www.osnews.com/story/139490/run0-a-systemd-based-more-secure-replacemen-for-sudo/ https://www.osnews.com/story/139490/run0-a-systemd-based-mor..., which points to this.
• jmclnx 2y ago
  Why ? I guess you do not get this unless you have systemd, that is fine by me. If I would use anything outside of sudo I would go to doas. My home distro does not have systemd, so I guess I may never see run0. I have been evaluating the various BSDs for a few years in case my distro is forced to use systemd and friends. The distro I use is fighting the good fight against large monolithic tools, but it is having a hard time trying to avoid these monolithic tools. With Linux slowly forcing systemd, Wayland, various Desktop Environments and now this, my move to a BSD may happen sooner that later. Curious, I wonder how close run0 is to how Windows raise auths ? With LP now working for Microsoft, is he cloning tools from Windows for use in Linux ?
• mise_en_place 2y ago
  This is just a complete disaster. Ever since libxz has shown how bloated and spaghetti code systemd is, now they want to make it seem like they're going to have "security" in mind. What a joke.
  • mzs 2y ago
    https://github.com/secnigma/CVE-2021-3560-Polkit-Privilege-Esclation https://github.com/secnigma/CVE-2021-3560-Polkit-Privilege-E...
  • deleted 2y ago
    [deleted]
• bhaney 2y ago
  Is it "run-zero" or "run-oh"?
• cesaref 2y ago
  Let's assume for a moment that it is lower risk than sudo (which is the problem is it addressing), why isn't it also called 'sudo', designed to behave the same as the thing it is replacing, so that anyone (and any scripts) that currently use sudo can carry on and be oblivious to the security benefits this new implementation offers? I'd instead like to see a post saying something like 'on systemd based systems, a more secure implementation of sudo is provided', and all the clever whatever it is happens behind the scenes, and frankly i'll never need to know about it.
  • agilob 2y ago
    Because there already is jq-go and jq-python. One of them is called jq in linux the other is called jq in MacOS. They are not compatible and you find out you're using the other one after 6 hours of screaming at the computer.
  • voiper1 2y ago
    calling it sudo would create the expectations that all the options, config, and usage is exactly the same. It would appear that it's _functionally_ the same, but using a different mechanism and with a new name so they don't want to be locked down to all the other stuff.
  • zzo38computer 2y ago
    Presumably because it uses different options and other different stuff, it has a different name. However, it might be useful to have a command "sudo" which emulates the options of sudo so that you can still use the same "sudo" command on systemd-based systems as well as on non-systemd-based systems. I don't really know how well that would work, though.
    • cesaref 2y ago
      Maybe you've not understood. I'm asking, why does it have different options? Is there a reason for that? If not, make it compatible, so a drop in replacement. Otherwise we're just spamming new commands at people, and the old sudo will probably end up living on alongside the new on systemd based systems just to keep scripts and the like working.
• andrew35424 2y ago
  [flagged]
• anonymous_union 2y ago
  holy shit this guy knows no shame
• tommiegannert 2y ago
  This is playing on the difference between hoping that sudo does the right thing juggling setuid and capabilities, and having a strict IPC boundary between privilege levels. It sounds like a great use of systemd, for those who want to use it.
  • AshamedCaptain 2y ago
    There's like 3 components involved in making setuid safe (the kernel, the dynamic loader, and your exec), and at least one of them wasn't doing its job correctly (the dynamic loader). IPC by definition involves a superset of these components. There's no reason to think that if you can't make a simple setuid binary safe, you can make IPC safe. IPC is an order of magnitude more involved. Specially because in order to gain any effective security you need a 3 way IPC (1st level = the client, which is completely untrusted; 2nd level = the request parser, which is trusted but runs without elevated permissions; 3rd level = the actual elevator process, which must run with elevated permissions).
    • EvanCarroll 2y ago
      It's not clear why the request parser would have to be trusted. I assume you're just speaking about the call to execve running in context? That's not much of a request parser. At the point that you tell `run0` to launch a shell, you're not calling the actual commands to the shell the request parser, right? I also think the notion of an untrusted client is kind of a hashed out thing. As said in the post itself, `run0` is an interface to `systemd-run`. `systemd-run` as a client may be more _involved_ but it doesn't seem like that has any relevance to whether or not it's more secure. It's a separate layer for the insecurity. While sudo is a single process, if it was two processes it wouldn't all have to run as root. That by necessity means something that was previously running as root isn't, which makes it more secure -- not less, right? The actual elevator process is systemd itself which already runs as init on every machine you'll have `run0`. But by nature it's always the top of the process tree, it seems like it's _less_ complex to have systemd-init the immediate parent process. There are fewer thing that can leak into or be inherited by the spawned process.
• nan60 2y ago
  Guess it’s time for me to switch to Void…
• hdmoore 2y ago
  [flagged]
  • deleted 2y ago
    [deleted]
• slackfan 2y ago
  Nope. I trust this about as far as I can throw it, and I will continue editing my own files. If I want NT, I'll just run an NT-based OS, thanks.
• Gualdrapo 2y ago
  [flagged]
  • deleted 2y ago
    [deleted]
• airocker 2y ago
  I have seldom come across unix multiuser environments getting used anymore for servers. Its generally just one user on one physical machine now a days. I understand run0's promise is still useful but i would really like to see the whole unix permission system simplified for just one user who has sudo access.
  • unixhero 2y ago
    The humans are now spawns of multithread shells and other things. Linux land is still very multiuser oriented. But it is the rise of the mschines instead.
  • TZubiri 2y ago
    access management is usually delegated to other systems that supervise UNIX, like AWS
    • airocker 2y ago
      Or Kubernetes. Thats where a standard way of authentication/authorization should be there.
  • rpgwaiter 2y ago
    NixOS may be helping multiuser make a comeback, at least it is for me and my home servers. I no longer have to containerize my apps, i can have one baremetal server with a dozen+ services, all with their own users and permissions, and i don't have to actually think about any of the separation. Plus there’s network shares. Multiple people in my home with linux PCs, each with their own slice of the NFS pie based on user perms. Sure, it’s not secure, but these are people I live with, not state-sponsored hackers. All that said, I’d also love a simpler single-user perm setup. For VMs, containers, etc it would be amazing
    • airocker 2y ago
      NixOS at it again :)
    • adastra22 2y ago
• gnufx 2y ago
  In fact, if factotum were implemented on Unix along with an analogue to the Plan 9 capability device, venerable programs like su and login would no longer need to be installed ‘‘setuid root.’’ — https://plan9.io/sys/doc/auth.html https://plan9.io/sys/doc/auth.html
  • opless 2y ago
    Plan9port has factotum. Plan9 has a completely different security model. The Hostowner (usually Glenda) is essentially "root" and you're at the mercy of the filesystem regarding file privileges etc. AFAIK there is no way to "become" glenda.
    • opless 2y ago
      In fact, according to sys/src/cmd/auth/login.c it looks like once you've logged it, you can shut the door using the capability device so then it's game over, no more hostowner for you
    • gnufx 2y ago
      I haven't followed Plan 9 for ages, but I'm puzzled why Cox & co wrote "Plan 9", then. However, the point was more about the capability-oriented security in a Unix successor, and how you can use file handles as a sort of cabability without the global namespace. (They're often quoted as examples capabilities in POSIX, but that's ignoring the global namespace.)
• broknbottle 2y ago
  sudo machinectl shell "${username}"@ sudo /usr/bin/systemd-run --machine="${username}"@ --quiet --user --collect --pipe --wait "${command}"
  • deleted 2y ago
    [deleted]
• Xeamek 2y ago
  2 weeks ago I didn't understood the systemd hate. But I tried to run udev-requiring program on non-systemd based distro. And now I don't like systemd anymore.
  • suprjami 2y ago
    So, you don't like a component because you ran software which requires that component, and you intentionally ran it in an environment without that component. That does not make sense to me?
    • rezonant 2y ago
      Well, I tried to run a Mac binary on Windows and it didn't work, so now I don't like Mac.
    • vpzom 2y ago
      The popularity of systemd encourages people to require it, which is the major problem that said iirc udev was formerly separate and active forks still exist
      • JoshTriplett 2y ago
        > The popularity of systemd encourages people to require it, which is the major problem The usefulness of systemd encourages people to require it. Projects most often require it in cases where either there isn't an alternative, the alternative isn't maintained, or the alternative is missing functionality.
        • Xeamek 2y ago
          Self perpetuating growth. Systemd integrates many functions so people default using it and add even more functionality that bring even more people into ecosystem. Which is basically how every tech ecosystem works. The problem is that linux is supposed to not be just_another_centrally_controlled_ecosystem, so when systemd abuses their popularity by enforcing whole ecosystem (rather then cut itself into separate pieces), that is worrying
• mynameisnoone 2y ago
  [flagged]
• hello_computer 2y ago
  fix pulseaudio and then we can talk.
  • yencabulator 2y ago
    Someone else did it and the better pulseaudio is called pipewire. Can't wait for that to happen to all the parts of systemd too, one day.
• gigatexal 2y ago
  I’m here for it. I like systemd for the most part. I don’t care for this red window tinting tho.
• ivanjermakov 2y ago
  Offtop: long mastodon/X threads are so inconvenient that I would not even consider it a use case of such platforms. Write a blog post and link it there, ffs
  • kasabali 2y ago
    Sadly there's no "interaction" in blog posts
  • hoherd 2y ago
    I am continually baffled at people's use of X-Twitter/Mastodon for this kind of writing. Thankfully I've found mastoreader, which is an equivalent of threadreaderapp. https://mastoreader.io/?url=https%3A%2F%2Fmastodon.social%2F%40pid_eins%2F112353324518585654 https://mastoreader.io/?url=https%3A%2F%2Fmastodon.social%2F...
• rstuart4133 2y ago
  I'm not a fan of sudo. It's does so much it needs BNF to describe it's configuration format. Who knows, maybe replacing the configuration with polkit is a good idea. Still it's a stand alone binary with one clear job to do, simple enough that one person has no trouble getting their head around it so it's not surprising it hasn't had too many problems over it's long life time. This made me smile: > sudo has serious problems though. It's a relatively large SUID binary, i.e. privileged code that unprivileged users can invoke from their own context. It has a complicating configuration language, loadable plugins (ldap!), hostname matches and so on and so on. That is a bit rich coming from the author of systemd, which must be in the running for one of the largest bodies of code that must run as root. It's also a very complex piece of code. That complexity is the reason I was completely flummoxed by interactions between systemd and dll's being exploited by the XZ utils hack to attack an unrelated and uncompromised binary: openssh. Run0 is just an extension of that ball of mud. It's a stretch to believe it will be more secure than sudo in the long term, which is amusing because it appears Lennarts primary argument is it will be more secure. I'm not the only one who has noticed this: https://lwn.net/Articles/971812/ https://lwn.net/Articles/971812/
  • throwaway7356 2y ago
    > which must be in the running for one of the largest bodies of code that must run as root Have you ever heard of the Linux kernel? Or X11 (which does traditionally run as root until systemd made it possible to not do so)?
  • dijit 2y ago
    Regarding your first point: some people agree, most notably the OpenBSD people who did something about it and wrote “doas” as a replacement; which fits the most common use-cases of sudo without fanfare.
    • logicprog 2y ago
      And, as LP points out, fails to solve the actual problem because it's still locked into the exact same flawed Unix model, and refuses to integrate with anything else in the system to get things done in a better more systematic way. It's just a slightly refined version of the same tired old Unix way
• righthand 2y ago
  The big switch to systemd was always a mistake and this announcement just proves it.
• kingspact 2y ago
  Linux is dead lol.
• udev4096 2y ago
  Just a side note: sudo is largely maintained by just one dude https://github.com/sudo-project/sudo/graphs/contributors https://github.com/sudo-project/sudo/graphs/contributors
  • calvinmorrison 2y ago
    [flagged]
  • rascul 2y ago
    For three decades. I suspect he hasn't seen much money for the work, but hopefully I'm wrong.
    • skywal_l 2y ago
      From his personal page: For the past 30+ years I’ve been the maintainer of sudo. I’m currently in search of a sponsor to fund continued sudo maintenance and development. If you or your organization is interested in sponsoring sudo, please let me know.[0] [0]: https://www.millert.dev/ https://www.millert.dev/
      • lenerdenator 2y ago
        Sounds like a prime candidate for the Linux, Apache, Mozilla, etc. foundations. Y'know. Before some strangely-named benefactor from within the UTC+03:00 time zone swoops in.
    • al_borland 2y ago
      Seems like that might be an issue. From his website… >I’m currently in search of a sponsor to fund continued sudo maintenance and development. If you or your organization is interested in sponsoring sudo, please let me know.
  • maxloh 2y ago
    So many critical components in our system are maintained by just a random good guy on the internet. I can't help but think of another XZ crisis that is yet to come. https://xkcd.com/2347/ https://xkcd.com/2347/
• ece 2y ago
  Over the years I've switched from various cron daemons (anacron, cronie), sysloggers (r-syslog, syslog-ng), network managers (netifrc, NetworkManager) even ssh servers/clients (dropbear, openssh), and init systems (sysvinit, openrc) and never have I felt the need to switch to systemd despite reading some of Lennart's posts. I've used Gentoo over the years, maybe that's why. Doas is available on Linux as a sudo alternative, I think I'll be trying that next, though I've only a limited amount of SUID binaries on my system to being with, and don't need sudo's extra features.
  • korhojoa 2y ago
    Now if then the commands run via some kind of privilege elevation mechanism would require pledges to be used, that would be awesome: https://news.ycombinator.com/item?id=38037075 https://news.ycombinator.com/item?id=38037075 "This needs root", okay. But you only get exactly what you need.
    • ece 2y ago
      It's not pledge, but firejail and other SUID binaries like it (bubblewrap, nsjail, etc..) are the only such ones on my system. It's better than grsec/chroot sandbox I used back in the day on Gentoo. I've also used shorewall, ufw, opensnitch for firewalls over the years. I could go on.
• orzi 2y ago
  Mother: We already have sudo at home HN: But, Mom!
• pkulak 2y ago
  But can I symlink sudo instead of run0? There are so many scripts that assume sudo, not to mention my own fingers.
• emmelaich 2y ago
  This is great! There was (is?) a program developed by some debian developers that did a similar thing way back, but I can't remember it. Anyone? [edit - https://www.chiark.greenend.org.uk/~ian/userv/ https://www.chiark.greenend.org.uk/~ian/userv/ is probably what I'm thinking of]
  • yonatan8070 2y ago
    I know of doas[1], but that appears to be an OpenBSD thing. Maybe Debian folks ported it? [1] https://wiki.archlinux.org/title/Doas https://wiki.archlinux.org/title/Doas
    • rfmoz 2y ago
      hopefully
• temptemptemp111 2y ago
  [dead]
• ykonstant 2y ago
  Is there a way to read this sequence of messages as a coherent whole in the correct order?
• DeathArrow 2y ago
  Someday systemd will going to replace Linux entirely.
• thayne 2y ago
  First of all, I like the idea. But I have questions. What does logging look like for this? I don't think it would be too difficult to log commands run with polkit, but is there an equivalent of sudo I/O logs? My guess is there isn't now, but to fully replace sudo it will probably need a way to record everything on the ptty it creates. What environment variables does it forward by default? From the man page it sounds like SHELL is. What about TERM? Any others? What environment variables are set? What is PATH set to? How are signals handled? Will a signal sent to the run0 process be propagated to the priveleged process? What about sudoedit? How would I achieve similar functionality with run0?
  • cl3misch 2y ago
    From the post: > well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist
• ccorcos 2y ago
  Can someone explain what this is / how it works to someone who has done a considerable amount of programming but lacks this kind of operating system level knowledge? I was under the impression that ‘sudo’ was baked into the entire system. Like ‘cd’ or ‘ps’. How exactly can you just swap out sudo? Does that involve swapping out chmod as well?
  • apexalpha 2y ago
    sudo, and even cd and ps you mention are simply binaries that come shipped with your distro / OS. They, like explorer.exe on Windows, are an essential part of that OS with special privileges and roles but they are not part of the kernel, they are still simply programs. It is not developed by the people who develop the Linux kernel. There are other Sudo alternatives such as DoAs already.
    • csande17 2y ago
      While some systems include a "cd" binary, it's basically useless since it just changes its own working directory and then exits. Instead, "cd" commands are generally parsed and executed by your shell (/bin/sh or similar) directly so that the shell's working directory gets changed and you can run subsequent commands in the new location. "ps" on the other hand is indeed just a normal program. Usually it reads files in /proc to figure out which processes are running.
  • tommica 2y ago
    Pretty sure `sudo` is an application that you can remove, it just comes pre-installed in many distros.
    • gattilorenz 2y ago
      Not only that, but it became commonly included only about 20 years ago. I spent my first years with Linux calling ‘su’ instead. I still run some very old distribution (e.g. RedHat 6.2) on a Pentium 1 laptop, and I downloaded the source of sudo and compiled it on it, since the sources were not even included in the extended CD set.
• j16sdiz 2y ago
  Oh, great. Adding another moving parts via IPC to essential system tool. Sure this would make recovery/rescue scenario more "fun".
• mvelbaum 2y ago
  Maybe this isn't a good idea? https://twitter.com/hackerfantastic/status/1785495587514638559 https://twitter.com/hackerfantastic/status/17854955875146385...
  • YtvwlD 2y ago
    If this is the only bug, then this is easily solvable: create the pty in the daemon.
  • TheDong 2y ago
    That "hack" uses reptyr to attach to the existing pty, which requires ptrace permissions. The same "hack" can be done against sudo if you ptrace attach to the shell that started sudo. This isn't a new issue. It's well known that if 'user1' has ptrace permissions, they can ptrace other processes for 'user1', and thus 'user1' can compromise 'user1'. If 'use1r' is also running sudo or run0 or anything else sensitive, it follows that the thing in the tweet is possible. This would be an issue if 'user2' could take over 'user1's pty or such.
• theshrike79 2y ago
  I think we're entering a point where GNU/Linux should be called Systemd/Linux
  • mrighele 2y ago
    That was the plan (by Redhat) all along, to have better control of the platform.
    • Spivak 2y ago
      To what end? It seems Redhat made a thing that solved a lot of their problems as distro maintainers and then made it OSS. This "control" doesn't really buy them anything.
• jimrandomh 2y ago
  > Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist). I think in practice, this is going to be an endless source of problems, so much so that it won't be adopted. The usual use case of sudo is that you have a normal shell command, making use of the environment for context in all the ways that shell commands do, but it doesn't have all the permissions it needs, so you add "sudo" as an adverb. Sometimes it makes use of environment variables. Sometimes stdin or stdout is redirected to a file, or to something more exotic than a file. Sometimes that means it runs inside of a chroot, or a Docker container. Sometimes you care about which process group it runs in. And sometimes the thing you're running is a complicated shell script or shell-script-like object, eg "sudo make install". In this case, you don't really know what its dependencies are. In fact this is a common enough case that, if run0 becomes widespread, I expect it'll have a flag or a set of flags that make it act exactly like sudo, and I expect people to wind up learning that they should always give run0 those flags. And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. I'm particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later.
  • yorwba 2y ago
    I don't know what your sudo does, but mine requires the --preserve-env flag if you want the new process to have access to all your environment variables. The thing you're saying is going to be an endless source of problems should already be an endless source of problems! (And I think I've been briefly confused by some missing environment variable once or twice so far.)
    • mid-kid 2y ago
      It depends on whether sudo was compiled with --disable-env-reset or not, it's on by default[1]. Also some variables are inherited regardless (e.g. DISPLAY, TERM), and some useful ones (e.g. HOME) are initialized by sudo, but I can't tell where that's done. [1]: https://github.com/sudo-project/sudo/blob/ef52db46f9b375d7ffd2e8893f1ef65f5b0fc014/configure.ac#L1279 https://github.com/sudo-project/sudo/blob/ef52db46f9b375d7ff...
• nottorp 2y ago
  Yeah, Pottering's quest to overcomplicate Linux continues...
  • PublicSimple 2y ago
    It’s fitting he’s now at Microsoft. That’s the MS way.
    • nottorp 2y ago
      You don't say... reminds me of the Nokia dude... Elop was his name?
• constantcrying 2y ago
  >But enough about all that security blabla. The tool is also a lot more fun to use than sudo. For example, by default it will tint your terminal background in a reddish tone while you are operating with elevated privileges. That is supposed to act as a friendly reminder that you haven't given up the privileges yet, and marks the output of all commands that ran with privileges appropriately. WHAT AM I READING?? Why can't the systemd developers just be normal? I also suspect that this will interact terribly with anyone who uses a certain kind of terminal theme. Do they not know that you can have these "nice to have" features, off by default, so that anyone who wants can enable them and anyone else is never bothered by them?
• Netch 2y ago
  A similar idea was tested in an experimental BSD clone in Berkeley in mid-1980s. (Great sorry I havenʼt kept link to the description, so rephrase with my own words. Maybe this was in the McKusickʼs book?) No suid or sgid was allowed. A daemon started from init and listening on a socket listened for connections, checked permissions and run the specified binary with requested permissions. A caller had to interact with the started program using pipes. It seems the complexity of passing all to pipes was why the approach was rejected. Instead, the checking of inherited environment was strengthened. "Everything new is well forgotten old."
  • lyu07282 2y ago
    44 years and ~20 local privilege escalation vulnerabilities later...
  • LNK_ 2y ago
    Listen socket (especially network socket), accept remote commands, and execute them as root. Sounds like a nice tool:)
• praseodym 2y ago
  There is also a write of sudo in Rust, which works more akin to the traditional sudo but memory-safe and with fewer bugs: https://www.memorysafety.org/blog/sudo-first-stable-release/ https://www.memorysafety.org/blog/sudo-first-stable-release/ Source code: https://github.com/memorysafety/sudo-rs https://github.com/memorysafety/sudo-rs And if you are running Debian 13 (trixie) or later, or Ubuntu 24.04 (Noble Numbat) or later, you can already install it using `apt install sudo-rs`.
• rmbyrro 2y ago
  Why use a short-form message social network to publish a blog post?
• chillfox 2y ago
  I am really not looking forward to systemd taking over another part of the system with how unpolished and flaky their replacements usually are. Anyway, I have been using doas instead of sudo for a while on servers, it’s rock solid if you don’t need some of the more advanced features of sudo.
  • 9dev 2y ago
    I honestly have no clue what you mean. You can take unit files, journald, timers, and all the other neat features from my cold, dead hands. I’m not going back to writing brittle shell scripts; systemd has made my life SO much easier.
    • chillfox 2y ago
      Well, that's wonderful for you, glad it works for someone, but that has not been my experience.
      • intelfx 2y ago
        In the same vein, sorry it doesn't work for you, but that has not been the prevailing experience ;) (Same goes for "unpolished and flaky".)
    • michaelcampbell 2y ago
      > I’m not going back to writing brittle shell scripts Then stop doing that.
      • klysm 2y ago
        Writing robust shell scripts ranges from hard to incredibly difficult. The number of footguns is insane
        • chillfox 2y ago
          It’s really not that hard. I have found that writing robust shell scripts is pretty easy. Don’t use bash, stick to #!/bin/sh, use shellcheck, wrap all variables in quotes, use command -v to check if a binary is available before trying to use it, and don’t use gnu specific things.
• isatty 2y ago
  I wish systemd would die or just be just an init system. This whole thread is people suggesting vague and non obvious solutions to things that people already knew how to do with just linux utilities now with some weird other binary.
  • bananapub 2y ago
    what a bizarre point of view. everything other than "being an init system" is a compile time option in systemd, so your complaint is that ... other people are building OSes and turning these things on? which OS are you working on that provides all these convenient features and large-scale integration of software with them, with code that isn't in systemd?
• Latrina 2y ago
  [flagged]
• lrvick 2y ago
  Between "systemd --user", Linux Capabilities, and containers there is no reason to ever have sudo, or the ability to touch the root filesystem at runtime at all, which should ideally be a signed, deterministic, and immutable image anyway. You can do anything as an unprivileged user these days without risking core system integrity and privilege separation guarantees. Remember, malware can just alias your sudo command to one that logs your password and piggyback on your next use. If you ever use sudo, then all bets are off on sandboxing malware. Best to not have a ladder to root at all. Sudo is a crutch for people that have not learned the last 20 years of privilege isolation tech.
• crest 2y ago
  So by design run0 does not do what sudo does. If I understand it correctly it has to stay a child of the daemon it's forked or does Linux provide an API to mangle the poor process table to change that since because according to POSIX the process would not part of the current session, or process group? How does this interact with (or break) shell job control since you can't forward SIGKILL. Does anything prevent the invoked process (which could also have less privileges) from holding on to the passed file descriptors e.g. the one to the callers controlling tty or is it restricted to always go through pipes/sockets/a fresh pseudo-tty?
  • crest 2y ago
    Okay further down it explains that it always goes through a fresh pseudo-tty (at least for interactive commands?). That solves the file descriptor passing problem but not the reliable signal handling for job control since there're signals you can't catch and forward.