what rich said. using a daemon is *actually* the proper UNIX way of doing this, and has no drawbacks from security POV over using an SUID. only benefits, really.
Conversation
I'm not starting to discuss the UNIX philosophy. Suid is the result of a shortcoming of this model just as having an intermediate deamon is. Both approaches have pros and cons, as already stated. We only disagree about the impact of the properties.
1
1
My main problem is, that the child process implicitly loses the context of the parent. Think of an environment where you work with network namespaces, you want to change the UID, but implicitly change the network context.
1
1
use the appropriate tools for that, `ip vrf exec` or `unshare` :p
1
Sure, there are ways to reconstruct the process state manually, but the fact that you need to do that requires knowledge about implicit behavior of the system.
1
I'm not saying the daemon approach is fundamentally flawed, but it changes many assumptions that have been established with sudo. And if it's about creating a replacement for sudo, please consider those instead of telling me how my opinion doesn't matter.
1
1
i should clarify: this is about creating a replacement for typical usecases of sudo, for use in the alpine base system. this is not about enabling all possible usecases that sudo allows.
1
alpine is not planning to remove sudo because it is known that creating a 100% replacement is not possible.
2
sshd with a restricted shell is essentially already an implementation of this. The concept of a restricted shell is the same very flawed approach as sudo policy and can have the same kind of logging.
You can make sshd listen on a Unix socket via the inherited fd support.
2
2
yes, but the ergonomics of doing it that way are somewhat problematic :p
2
It's pretty easy to wrap into something useful. I just don't think the whole restricted shell or sudo policy concept is a good idea.
Main usage of sudo is simply to delegate full access to an account in which case you might as well just add that SSH key to the authorized_keys.
in our case, the primary goal is to enable maintainer scripts that need privilege escalation to continue working (e.g. to restart a service), when sudo is removed from main.
while we will support something like `sudo -si` I agree with you that SSH keys are more appropriate
Very rarely do I see sudo used as you describe. Most enterprises I work with use the policy stuff albeit (in many cases) badly.
1