Explanation for newbies: setuid is a special permission bit that makes an executable run with the permissions of its owner rather than the user executing it. This is often used to let a user run a specific program as root without having sudo access.

If this sounds like a security nightmare, that’s because it is.

In linux, setuid is slowly being phased out by Capabilities. An example of this is the ping command which used to need setuid in order to create raw sockets, but now just needs the cap_net_raw capability. More info: https://unix.stackexchange.com/questions/382771/why-does-ping-need-setuid-permission. Nevertheless, many linux distros still ship with setuid executables, for example passwd from the shadow-utils package.

  • corsicanguppy@lemmy.caEnglish
    3·
    8 days ago

    In linux, setuid is slowly being phased out by

    … brittle resume-based non-unix neu tools designed to encourage quiet balkanization and vendor/dev lock-in after being pushed by vendor payola.

    See:

    • Systemd bag of festering wunderkinder shit,
    • networkManager and its 6 different competing manager-manager tools, and
    • anything else created in the dark post-mentor ages when “move fast and break things” was dreamed up by people who didn’t give a fuck about must-work tools because must-work wasn’t on their final exam at udemy.
    • renzev@lemmy.worldOP
      1·
      21 hours ago

      Systemd and network manager are deliberately malicious I’m with you on that one but I feel like the new kernel-specific features like capabilities and namespaces are actually pretty neat. Like, they don’t even break backward compatibility. If you had a program that needs a special capability on linux and you wanted to port it to bsd, you could just make it a SUID executable. It’s not like capabilities offers a new API that programs use or something. Same with namespaces. I see a lot of people complaining about docker somehow being bloat or something, but, like, it’s still just linux on the inside of the container. Anything that can run in docker can run just as well outside of it. Worst-case scenario is that you have to change some environment variables from host.docker.internal to localhost. You’re not being forced to use it.