On Tue, Sep 30, 2014 at 07:52:02AM -0700, Zac Medico wrote: > On 09/29/2014 04:31 PM, Steven J. Long wrote: > > On Mon, Sep 29, 2014, Zac Medico wrote: > >> On 09/28/2014, Steven J. Long wrote: > >>> On Wed, Sep 24, 2014, Zac Medico wrote: > >>>> 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). > > > > Yeah but think it through; the "elevated process" inherits its environment > > from us (current state, as normal). It runs a child process: nothing in the > > env of that child is going to affect our env, by definition. The command > > completes, and we save back the same env we started with. > > > > Sure, the child inherits its env from us, but we don't need to do anything > > to make that happen: it's standard. In fact we take efforts to clean the > > env in some situations for that reason. > > > > I just can't see it working, apart from perhaps where a command outputs > > settings which should be run through eval. In which case, eval them > > in ebuild space after the command has output whatever under esudo. To > > be flexible, you're going to want to save them anyway for later use, > > which again implies that happening in the ebuild/eclass. > > You're thinking in terms of a SUID helper like sudo. The implementation > that I've been suggesting does not involve a SUID helper.
No, I'm thinking in terms of "a process with elevated privileges" running "a specific command"; whether that first process is started by us or not, is irrelevant to whether it can get the environment from a child process we have no control over, after it "completes". Sure it can save its own, but since it's a generic "run any command" helper, it can't do much more than give us back what we gave it, unless you're talking about echoing back settings, in the manner of gpg et al, which by definition is not about the saved env. That's why we have to use that format in the first place; because the env setting must be done by the process which wants to use it (have it inherited for child processes), for the same reason: a child process can never affect the parent env. > Instead, IPC > would be used to request that the privileged parent process launch a new > privileged process on behalf of esudo. In this context, unless the esudo > implementation provides explicit support for environment inheritance, > the new privileged process will not inherit any environment from the > environment where esudo was called. Well, assuming that were the implementation, that explains why you'd want to save the env off, so that the privileged helper can access it. It still sounds like more work in the long run in terms of what's happening, but regardless: it doesn't get you the resultant env from the child command. But like I said, that's of dubious utility in any case. I think we should just forget about it. > > So we already have to deal with the user part of userpriv, as admins. > > > > On the implementation side, it makes a lot of sense: we delegate the > > worry to a package used cross-distro for this specific purpose. In fact > > this conversation has made me understand ubuntu a bit more, where I > > always used to smile at the overuse of sudo. I certainly wouldn't > > want the implementation headache of maintaining a secure clone. > > The IPC implementation that I've suggested does not involve an SUID > helper, so it is much more secure. Security would rely on the permission > bits of the named pipes that are used to implement IPC. I see, so presumably there's a fifo pair, that only the portage user can access (likely at dir level too), one read-only? On the other end of which you have a waiting process, ie a daemon, in the classic sense, with root privilege, so it can run any command as any user, with any set of caps required. If you're using IPC to request a process with privilege be launched, something's got to be listening to the other end. I don't see how that's "more secure", but then I don't really care how you implement it, either ;) It's certainly less deps, I guess. It still just sounds like a reimpl of sudo, by an indirect method (root userland daemon, as opposed to kernel suid) leading to a lot more going on at runtime (env saving to file, reloading in a new child process from the privileged daemon, before we can start the actual command.) And as above, it cannot get us the env after randomcmd completes, but that's orthogonal, since nothing can, and programs aren't written to output to their env, since the parent can't access it. I assume you have code in mind for this already, perhaps from another project? If so, and it's a reasonable maintenance burden, ie not much needs to change once it's up and running correctly, then fair enough. Though from what I've seen even Linux-specific projects just exec the command, after setting privileges, namespace etc as appropriate, from a suid helper. Are you sure you don't want to borrow someone else's code for a suid helper instead? Not sure what a daemon buys you, apart from extra maintenance overhead (listener, loading env, as well as what a suid helper would do, and a protocol for communication, which no doubt is going to change over time) plus an attack vector for someone who can crack portage or python at any future point, or just get portage uid via some other vector; for a relatively infrequent operation. Regards, igli -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
