On 09/28/2014 09:23 PM, Steven J. Long wrote: > On Wed, Sep 24, 2014 at 09:51:31PM -0700, Zac Medico wrote: >> On 07/09/2014 07:17 AM, Michał Górny wrote: >>>>> c) 'esudo' helper [3]. This is a more generic form of (2), with >>>>> support for other potential privilege changes. >>>> > .. >>> I don't think we'd use the reference 'sudo' impl. Rather some >>> in-portage helper, possibly setuid. Or portage's IPC but that would >>> imply running the command in an isolated environment (possibly >>> beneficial). >> >> The environment doesn't necessarily have to be isolated, since we could >> extend the existing environment saving/loading support to be used for by >> esudo. The steps to implement the shared environment could be as follows: >> >> 1) When esudo is called, it saves the current (unprivileged) bash >> environment to a file. >> >> 2) esudo uses IPC to request that a process with elevated privileges be >> launched to run a specific command using the saved environment, and that >> the environment of the elevated process be saved to a file after the >> command completes. > > I don't think it's going to be quite that easy to get the output env, > certainly not from some random command; tbh I don't even see the need > for it, unless I'm missing something. From the "elevated process" after > it waits on the child, but not from the child unless you control the > code.
We control the shell code that launches the requested command, so we can save the environment after the requested command completes (using a modified version of our existing environment persistence code). >> 3) Before esudo returns, it loads the environment that was saved by the >> elevated process before it exited. > > What's the use-case for this part? I could see it with a function, but > then you just run that as part of the ebuild. For running a specific > command to access a device with privilege, or to add a user etc, I > don't really see the point. (so why bother with the implementation > complexity.) Well, maybe it's not very useful. I just thought I'd mention it in case anyone found it useful for some reason. > Other than that, I agree esudo is the best approach, and gives us > much better granularity over privilege escalation, as discussed in > the bug. Yeah, me too. > Part of me thinks though, that it'd be much cleaner to give the > portage user access to sudo. Isn't that effectively the purpose > of the "suid helper"? In which case we get all the options for > env etc, of sudo, and the admin gets to configure it along with > the normal wheel setup. Depending on our goals, using sudo may or may not have advantages. It. really depends on whether or not we want esudo to interact with the local sudo configuration. If we want it to be independent of the local sudo configuration, then it makes sense for the package manager to use it's own privilege escalation mechanism. -- Thanks, Zac
