Run as usual, or run for the hills?
  • kenkenken@sh.itjust.worksEnglish
    881·
    5 months ago

    I will use it. I don’t care what others think. People can use su, sudo, doas, run0 by their choice, and I don’t see why we need a common opinion about it.

  • LainTrain@lemmy.dbzer0.com
    652·
    5 months ago

    If you make users sign in too much, they will just make their passwords short and easy to remember, even 24hrs is too much and people bitch about it all the time, especially since we have password managers enforced, meaning every time they need to Auth they need to Auth into their system, Auth into their password manager, copy the password, auth into their phone, look at the 2FA code and type that in.

    Doing this every day just to open email is understandably fucking enraging even to me as a security “”“engineer”“”/analyst/${bullshitblueteamemailreaderjob}

    Press it harder and they will use simple passwords that will inevitably be passed through to something external (e.g. cockpit which even I can bruteforce) or reused somewhere at some point, and then someone just has to get lucky once and run whatever run0 sudo su to bypass all protections.

    • TBi@lemmy.world
      8·
      5 months ago

      I agree with you. If i had to add my password everytime I’d just add my personal account to sudo group.

      Good security works with people, not against them.

      • Vilian@lemmy.ca
        51·
        4 months ago

        ok them go suffer alone in your 2004 distro that can’t update bash because it break the 400 scripts that it use to boot lmao

  • exu@feditown.comEnglish
    40·
    5 months ago

    I might try run0 for fun, but I don’t think it’ll replace sudo any time soon.
    The biggest issue I see is run0 purposely not copying any environment variables except for TERM.
    You’d have to specify which editor to use, the current directory, stuff like PATH and HOME every time you run a command.

    • kbal@fedia.io
      61·
      5 months ago

      I’m not a fan of the idea at all, but come on, it can’t really be that bad. There’s got to be somewhere you can tell it what environment variables to use. Probably something like run0 systemd-edit /usr/system/systemd/systemrun/run0-environment --system-default=system

      • exu@feditown.comEnglish
        2·
        5 months ago

        You can’t really install packages or modify configs on the host without root. Containers can only do some parts.

      • exu@feditown.comEnglish
        1·
        5 months ago

        Maybe, but now I still need to remember the alias or distribute it to any machine I’m working on.
        Not that difficult if you have everything managed with Ansible or similar anyways, but lots of people likely don’t have that setup.

    • qaz@lemmy.world
      142·
      5 months ago

      sudo has more than 220k lines of code, I can definitely see the use of a simpler alternative.

        • TMP_NKcYUEoM7kXg4qYe@lemmy.world
          4·
          5 months ago

          run0 is just an alias for a part of systemd, so installing doas too would be useless bloat. Another thing to note is that doas is just smaller sudo, you still wouldn’t use 99 % of its features.

          edit: also from my totally surface level understanding both sudo and doas “elevate your privileges” which is supposedly unnecessary attack surface. run0 does it in a better way which I do not understand.

          • Laser@feddit.org
            8·
            5 months ago

            also from my totally surface level understanding both sudo and doas “elevate your privileges” which is supposedly unnecessary attack surface. run0 does it in a better way which I do not understand.

            sudo and doasare setuid binaries, a special privileged bit to tell the kernel that this binary is not run as the user starting it, but as the owner. A lot of care has to be incorporated into these to make sure you don’t escalate your privileges as the default interface is very limited, being a single bit.

            Another issue with this approach is that since you’re running this from your shell, the process will by default inherit all environment variables, which can be convenient, but also annoying (since a privileged process might write into your $HOME) or upright dangerous.

            run0doesn’t use that mechanism. systemd is, being a service manager at its core, something launching binaries in specialized environments, e.g. it will start an nginx process under the nginx user with a private tmp, protecting the system from writes by that service, maybe restrict it to a given address family etc. So the infrastructure to launch processes – even for users via systemd-run– is already there. run0 just goes one step further and implements an interface to request to start elevated (or rather with permissions different from their own) processes from a user’s shell.

            Classic solutions do it like this:

            1. user starts binary with setuid (let’s say sudo) that runs with root (because that’s the owner of the binary) privileges in their shell. Since this is a child process of their shell, it inherits all environment variables by default.
            2. sudochecks /etc/sudoers if that user is authorized to perform the requested action and either denies the request, performs it or asks for authentication.
            3. a new process is spawned from it, again inheriting the environment variables that were not cleaned, as you can’t get rid of variables by forking (this is often an issue if you have services that have their secrets configured via environment variables)

            With run0:

            1. user starts run0 binary as a user process. This process inherits the environment variables.
            2. run0 forwards the user’s request via interface to the running systemd process (pid 1 I guess). That process however does not inherit any variables by default, since it was started outside the user’s shell.
            3. systemd checks if the user who started the run0 binary is allowed to perform the requested operation and again, either denies the request, performs it or asks for authentication.
            4. a new process is spawned from it, but it will only receive the environment variables that were explicitly requested as there’s no inheritance.

            At least that’s my understanding, I haven’t looked too much into it or used it yet.

            • Vilian@lemmy.ca
              3·
              4 months ago

              the pid1 part is wrong, only the systemd-init run in pid1, in it’s own process, own binary etc, it’s sole purpose is being an init system, after that it start the rest of the system, including the others systemd binaries

              the rest is perfect thanks!, in the lennart he made a comparation with ssh were you “forward the commad to run as root”, i think it’s a good analogy

          • Vilian@lemmy.ca
            2·
            4 months ago

            . run0 does it in a better way which I do not understand.

            it does that in a “ssh like” that i read in the blog, they foward your commands, they don’t elevate your user, they also use polkit for security intead of sudoers

    • TMP_NKcYUEoM7kXg4qYe@lemmy.world
      2·
      5 months ago

      The original problem was to automagically prompt the user for password, if he tried to run some systemd executable without the wheel privileges. At some point they decided to reuse the code for [a command that allows you to run stuff as root] replacement because sudo is too bloated and vulnerable.

    • TMP_NKcYUEoM7kXg4qYe@lemmy.world
      3·
      5 months ago

      imo it’s kinda like bash’s bloatness. Sure, I’d use a less bloated shell but I need bash as a bash interpreter regardless, so using a smaller shell would actually be more bloat. In a similar way you already have systemd, so you don’t really gain any more bloat by having this alias for systemd-run or how it’s called.

    • wer2@lemm.ee
      241·
      5 months ago

      Also, you can configure sudo to prompt every time if you really want.

      I was on a system that was configured that way for “security”, so I would just ‘sudo bash’ which is obviously much safer /s.

      • MadMaurice@discuss.tchncs.de
        5·
        5 months ago

        My system is configured that way (by me) and I regularly use sudo -s.

        I just want to see if there’s a root shell and not rely on some hidden timeout 🙄

        • wer2@lemm.ee
          1·
          5 months ago

          The beauty of Linux at home, you get to choose what works best for you.

    • TMP_NKcYUEoM7kXg4qYe@lemmy.world
      21·
      5 months ago

      Yeah I mean at that point it’s redundant because you might as well type su -c “some command here”. On the other hand having such alias does no harm if you’re already using systemd.

  • onlooker@lemmy.ml
    14·
    5 months ago

    I don’t know, we’ll just have to see. But personally, I am not a fan of tying so many functionalities to systemd.

  • Kaity@leminal.spaceEnglish
    132·
    5 months ago

    As it is running sudo with a long process is annoying missing and having to reenter my password or missing and the process timing out if I go afk to wait, I can’t imagine having to type my password every few moments when I run an upgrade. Surely this is not the pitch. This is already looking dead in the water if so, and god help me if I have to remember to type run0.

  • mexicancartel@lemmy.dbzer0.comEnglish
    154·
    4 months ago

    su is the best. I mean, i should be using the admin (root) password for admin things, not the user password of user who is already logged in. And there needs to be a root service already running to make user have root previlages which is dumb imo. Sudo vulnerability could cause previlage escalation but if there is no root process managing this, then it can’t leak the root access. Only kernel security issue(or other root processes) will leak root access if that was the case, which i think is better.

    • Cryxtalix@programming.dev
      4·
      4 months ago

      The permission to do admin things is given by the root user, to your account. So you have to verify your identity by entering your password.

      Isn’t that how it is? I though that was analogous to how almost everything worked IRL. Whether withdrawing funds from a bank or engaging government services, you prove your identity as a customer/citizen to get the relevant services. At no point do you login to bank or government computers with full privileges.

      • mexicancartel@lemmy.dbzer0.comEnglish
        2·
        4 months ago

        If you own your own bank, then i think you login as the one with full previlages. Yes when doing administrator things, you have to use sudo. The problem with root with sudo is, you authenticate as a user, then gain full permission from root, i.e analogous to login in to bank with full previlages.

        As a person who need to run sudo command its better to just verify yourself as root user to gain “full access”. I’m not saying about partial previlages. That is i just need a script which is just su -c with environment variables being copied

        • theshatterstone54@feddit.uk
          1·
          4 months ago

          I see where you’re coming from, but in enterprise environments, you have admin accounts and root login is disabled for security purposes.

  • AndrewZabar@lemmy.world
    10·
    5 months ago

    I’m surprised they would implement having just run0 effectively log you in as root. For the super security conscious constrictions of the command versus sudo, it would seem that the very notion of elevating your privilege beyond the single command to be carried out, would be anathema to the whole goal of this new command. Evidently not, but it’s surprising to me.

    • Vilian@lemmy.ca
      12·
      4 months ago

      you can run a command using run0 it’s only elevating that commads, sometimes it’s needed to login as root, it’s life

        • LeFantome@programming.dev
          31·
          4 months ago

          They did not miss anything. They just used commas where periods should be.

          You can run a command using run0. It’s only elevating that command. Sometimes it’s needed to login as root. It’s life.

          The way it is written, semi-colons may be more appropriate but that would be a lot of them.

          • laughterlaughter@lemmy.world
            11·
            4 months ago

            You actually pointed out that they did, indeed, do miss a period (the one after “run0.”)

            you can run a command using run0 it’s only elevating that commads,

  • Ada@lemmy.blahaj.zoneEnglish
    101·
    5 months ago

    At the moment, fish doesn’t know what to do with run0. When that changes, I’ll start using it :)

    • PoorPocketsMcNewHold@lemmy.mlEnglish
      3·
      5 months ago

      Speaking of doas, is there any advantage of using it when… sudo is still available to be used? I agree that most of the stuff we require to use doesn’t need all the options sudo as, but if it is for the sake of security, maintenance, and stability… is there any reason to use doas ON TOP of the already setup sudo or su? In the past, I even tried to just apply a simple alias to replace sudo with doas, but numerous scripts and programs when trying to request explicit super-user permissions, just didn’t know what to do with doas as expected, so this ain’t it.

      • Titou@sh.itjust.works
        3·
        5 months ago

        I agree that most of the stuff we require to use doesn’t need all the options sudo as

        Main reason of using doas

        but numerous scripts and programs when trying to request explicit super-user permissions, just didn’t know what to do with doas as expected

        I’ve only found one software like that and it’s tipi, and it’s kinda dumb for a software to require such a easily replacable software. Also how openbsd users are supposed to do ? Having both doas and sudo on their machine which is unnecessary bloat ?

        • PoorPocketsMcNewHold@lemmy.ml
          1·
          4 months ago

          Sure do confirm that hard-coded sudo requirements are kinda dumb. But this proove systemd point. BSD mainly use doas. Linux mainly use sudo. Why not have an universal method for true cross-platform compatibility ? (Yes, I know plenty prefer or explicitly are against the usage of systemd suite of software, was pointing out systemd main reason of planning to propose an another standard, regardless if it will be popular or not)

        • PoorPocketsMcNewHold@lemmy.ml
          1·
          4 months ago

          When was the last time you had to edit sudo configuration file ? Same goes for doas. It’s has nothing going for, for the majority of desktop Linux users (from what I got as an answer)

  • steeznson@lemmy.world
    135·
    5 months ago

    I’m going to continue to keep avoiding Poettering software for as long as he continues to act like a jackass. Even his commit messages are dripping with condescension.

    • shapis@lemmy.ml
      201·
      5 months ago

      Funny. I didn’t know a single thing about the person. But that commit message made me like him more.

      Ofc assuming he was just making a light-hearted joke in it.

      • steeznson@lemmy.world
        121·
        5 months ago

        Users were complaining that their terminal transparency was being broken by the nspawn container and that the colour for other applications like tmux were being affected by it. For example tmux was appearing in the same navy blue in the terminal emulator instead of its usual green.

        Idk he’s just a hot take merchant basically. He has a particular hate-boner for distros that don’t use systemd as the default init system like void and gentoo (usually these are troll tweets as opposed to commit messages though).

        • Vilian@lemmy.ca
          211·
          4 months ago

          Idk he’s just a hot take merchant basically. He has a particular hate-boner for distros that don’t use systemd as the default init system like void and gentoo (usually these are troll tweets as opposed to commit messages though).

          shut up, wtf that has todo with the commit, people who don’t use systemd it’s not going to complain about the color of something that they don’t use