111–114 of 114 posts
> I changed the root password If you're going to set a root password, you might as well just do this and if I'm not mistaken it accomplishes everything you want alias sudo="su -c"
alias sudo="su root -c"Earlier quoted context omitted.
This premise is incorrect: SSH doesn't need to be an suid binary because it's already running as root, and then SSH creates a new environment for the user, exactly like sudo does, but with all the added complexity and overhead (and surface) of privileged network access. To be clear, I love SSH and we even run a userify instance to distribute keys, but juts comparatively the surface area of the ssh daemon alone is gre…
But the area under control by the invoking user is data over one socket vs the whole calling environment e.g. environment vars, local files. Surely that counts for something.
My main objection to this is just the added complexity. Instead of a single suid binary that reads a config file and calls exec(), now you have one binary that runs as root and listens on a UNIX socket, and another that talks to a UNIX socket; both of them have to do asymmetric crypto stuff. It seems like the main argument against sudo/doas being presented is that you have a suid binary accessible to any user, and if…
> And since the sshd approach doesn't allow you to restrict root access to only certain commands [...] The ForcedCommand infrastructure.
shameless plug: you can prevent this by https://github.com/bAndie91/tools/tree/master/ssh-groupcomma...
Isn't this what systemd run0 is now doing? 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) 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. I…