Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced

[J. Bruce Fields]

On Thu, May 23, 2013 at 09:05:26AM -0400, Jeff Layton wrote:
> On Thu, 23 May 2013 15:25:20 +0300
> > I'm not familiar with nfsdcltrack but I would imagine it receives it's information from
> > Kernel as a command line parameters.
> > 
> > Would it not be the simplest approach to add a --chroot=/path/to/root optional
> > parameter to nfsdcltrack so it should access an alternate DB relative to 
> > --chroot.
> > 
> > This would address Eric's concern of not executing user-privileged executable
> > from Kernel. I think
> > 
> > Just my $0.017
> > Boaz
> > 
> 
> I think that sounds reasonable. Is it always the case
> that /path/to/root is reachable from the "primary" namespace?

I don't think we can assume that.

> If not, you may need to do something more exotic there.

We should be able to pass a file descriptor and then work relative to
that.

> Also, do you have to do anything like change the uid/gid to a different
> user who is root within the container?

Yeah, you may need to create files, for example, right?

> What might help most here is to lay out a particular scenario for how
> you envision setting up knfsd in a container so we can ensure that it's
> addressed properly by whatever solution you settle on.

It would seem cleaner to me the less userspace has to understand about
containers--ideally someone could run a general-purpose distro with its
nfs-utils in a container and have nfs and nfsd just work.

So I'd like to understand whether it is feasible to spawn helpers from a
thread that's descended from whoever started nfsd (or whatever the
proper ancestor is).

(And, what about the nfsd threads themselves?  If we're going to allow
unprivileged users to start nfsd, then we probably want the nfsd threads
to inherit from the user somehow, don't we?)

As I understand it recent clients use request_key to do idmapping.  I
don't understand that (or keyrings) well.  How should they work?  I
would have expected that you'd want a separate request-key for each
container rather than a single request-key working on behalf of all
containers.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/