Peter Stuge wrote: > Steven J. Long wrote: > > > It's a lot more secure to have a single well-defined privileged trust > > > anchor (the privileged process) with a well-defined protocol, than to > > > have built-in privilege escalation which allows arbitrary actions. > > > > the whole point is to run arbitrary commands that affect the root system. > > I don't think that's the case. Are you sure that it is?
Ah I see, so you're saying it's limited to a small allowed set of whitelisted actions? Sorry was under the impression it was a generic "esudo whatever" esoteric command might be required for build-system X to communicate with driver Y, perhaps as a specific user. > With a trust root of our own it is very easy to decide what is allowed > and I imagine that we want to. > > I'm sure you see the vast difference between built-in privilege > escalation for a user process and having a separate, controlled, > code path with privileges. > > You claim that they are the same, but unless the protocol supports > transfering machine code for privileged execution that's plain wrong. > > Maybe you tend to support such arbitrary code execution, but I don't > think that's what is being proposed here, and a lot of people have > done just fine designing and implementing protocols without such > problems in the past. > > And you have a very long way of saying that you don't care. :) Yeah, sorry for going on. Having thought about it, if emerge is the listener, and the ebuild or the monitor is its child running the install phase (or similar) then it doesn't even need named IPC. In any case the listener would only be active when emerge is running, started by root. If you were to go that route a Unix domain socket would be better than a fifo, as you could then get peer credentials to verify the pid at the time of execution, and directory access perms would still apply. Apologies again for noise. steveL. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
