linux-kernel - Re: [RFC PATCH] fs: call_usermodehelper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 23 May 2013 15:55:47 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	Boaz Harrosh <bharrosh@...asas.com>,
	Stanislav Kinsbursky <skinsbursky@...allels.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	viro@...iv.linux.org.uk, serge.hallyn@...onical.com,
	lucas.demarchi@...fusion.mobi, rusty@...tcorp.com.au,
	linux-kernel@...r.kernel.org, oleg@...hat.com,
	linux-fsdevel@...r.kernel.org, akpm@...ux-foundation.org,
	devel@...nvz.org
Subject: Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/