3 ms·

Setuid programs like pkexec or sudo are hard to get right… Here an example of using systemd-run (not setuid, and the wrapper script neither) for something simil

Setuid programs like pkexec or sudo are hard to get right… Here an example of using systemd-run (not setuid, and the wrapper script neither) for something similar like sudo (but it uses a systemd unit instead of a direct child process in the same process group): https://gist.github.com/pothos/73dd4f7694acc3b6bbed614438f6e2b1 https://gist.github.com/pothos/73dd4f7694acc3b6bbed614438f6e... Since polkit is used (but not the setuid pkexec, this was the point of this exercise) there is still one setuid binary invoked for the PAM check, though.

remram 5y ago
Doesn't --scope run the process as a child? Is this done without setuid?
- Klasiaster 5y ago
  It won't be a child process because PID 1 will actually start this unit. Yes, without setuid because PID 1 takes the request from the unprivileged systemd-run client.
  - remram 5y ago
    I said with --scope: > If a command is run as transient scope unit, it will be executed by systemd-run itself as parent process and will thus inherit the execution environment of the caller. (...) This mode is enabled via the --scope switch
throwawayboise 5y ago
Sudo got so complex that OpenBSD replaced it with their own much simpler "doas." But even doas has grown some additional features since it was first released.
- nerdponx 5y ago
  What's the origin of this complexity? Too many configurations and settings? The project being really old and lacking a strong culture around software architecture? Something else?
  - throwawayboise 5y ago
    I believe it's mostly years of "creeping featuritis" but I don't really know the history in detail. Just read the sudoers(5) manpage and let the sense of hopelessness slowly overtake you.
    - foxfluff 5y ago
      There's irony in the man page telling you not to despair. There's an xkcd about it: https://xkcd.com/1343/ https://xkcd.com/1343/ By comparison, the manual to doas.conf is pretty short: https://man.openbsd.org/doas.conf.5 https://man.openbsd.org/doas.conf.5 It seems like OpenBSD was also stuck on an older version of sudo when it was removed. It's possible they just weren't having all the churn of such a large tool? But then they also missed a bunch of important fixes: https://marc.info/?l=openbsd-bugs&m=142270265216628&w=2 https://marc.info/?l=openbsd-bugs&m=142270265216628&w=2 More: https://marc.info/?l=openbsd-ports&m=143465998814989&w=2 https://marc.info/?l=openbsd-ports&m=143465998814989&w=2

remram 5y ago

Doesn't --scope run the process as a child? Is this done without setuid?

Klasiaster 5y ago
It won't be a child process because PID 1 will actually start this unit. Yes, without setuid because PID 1 takes the request from the unprivileged systemd-run client.
- remram 5y ago
  I said with --scope: > If a command is run as transient scope unit, it will be executed by systemd-run itself as parent process and will thus inherit the execution environment of the caller. (...) This mode is enabled via the --scope switch

throwawayboise 5y ago

Sudo got so complex that OpenBSD replaced it with their own much simpler "doas." But even doas has grown some additional features since it was first released.

nerdponx 5y ago
What's the origin of this complexity? Too many configurations and settings? The project being really old and lacking a strong culture around software architecture? Something else?
- throwawayboise 5y ago
  I believe it's mostly years of "creeping featuritis" but I don't really know the history in detail. Just read the sudoers(5) manpage and let the sense of hopelessness slowly overtake you.
  - foxfluff 5y ago
    There's irony in the man page telling you not to despair. There's an xkcd about it: https://xkcd.com/1343/ https://xkcd.com/1343/ By comparison, the manual to doas.conf is pretty short: https://man.openbsd.org/doas.conf.5 https://man.openbsd.org/doas.conf.5 It seems like OpenBSD was also stuck on an older version of sudo when it was removed. It's possible they just weren't having all the churn of such a large tool? But then they also missed a bunch of important fixes: https://marc.info/?l=openbsd-bugs&m=142270265216628&w=2 https://marc.info/?l=openbsd-bugs&m=142270265216628&w=2 More: https://marc.info/?l=openbsd-ports&m=143465998814989&w=2 https://marc.info/?l=openbsd-ports&m=143465998814989&w=2