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]

Message-ID: <20130523073108.13afafa6@tlielax.poochiereds.net>
Date:	Thu, 23 May 2013 07:31:08 -0400
From:	Jeff Layton <jlayton@...hat.com>
To:	Stanislav Kinsbursky <skinsbursky@...allels.com>
Cc:	"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>,
	<bfields@...ldses.org>, <bharrosh@...asas.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, 23 May 2013 14:35:53 +0400
Stanislav Kinsbursky <skinsbursky@...allels.com> wrote:

> 23.05.2013 14:00, Eric W. Biederman пишет:
> > Stanislav Kinsbursky <skinsbursky@...allels.com> writes:
> >
> >> 22.05.2013 21:33, Eric W. Biederman пишет:
> >>> Stanislav Kinsbursky <skinsbursky@...allels.com> writes:
> >>>
> >>>> Usermode helper executes all binaries in global "init" root context. This
> >>>> doesn't allow to call a binary from other root context (for example in a
> >>>> container).
> >>>> Currently, both containerized NFS client and NFS server requires an ability to
> >>>> execute a binary in a container's root context. Root swap can be done in
> >>>> "init" callback, passed by UMH caller.
> >>>> But since we have 2 callers already (and more of them are expected to appear
> >>>> in future) and because set_fs_root() in not exported, it looks reasonable to
> >>>> add one more generic UMH helper to generic fs code.
> >>>> Root path reference must be hold by the caller, since it will be put on UMH
> >>>> thread exit.
> >>>
> >>> Awesome.  With this patch as an uprivilieged user I get to pick which
> >>> binary the kernel will execute.  At least if nfs and nfsd ever runs in a
> >>> user namespace (something that looks like only matter of time).
> >>>
> >>
> >> Not really. Only by using a kernel module to call the UMH.
> >> And an unprivileged can't load a module as far a I know.
> >> I.e. NFSd, for example, will use unprivileged user's root to perform this call.
> >
> > To help me understand the context which instances of call user mode
> > helper are you expecting to use this facility?
> >
> 
> Ok. Here is how the NFSd uses UMH:
> UMH is used on NFSd service to start user-space client tracker daemon
> ("/sbin/nfsdcltarck"), which is used to store some per-client locks data on
> persistent storage.
> 
> >>> I think this is a seriously bad idea.
> >>>
> >>> Why can't we do this in userspace with setns as we do with the core dump
> >>> helper?
> >>>
> >>
> >> Could you, please, clarify, how setns can help here?
> >
> > setns can change the mount namespace, and chroot can change to root
> > directory in the specified mount namespace.  Essentially you can enter
> > into a containers complete context (pid, mnt, root, etc) comming from
> > the outside.
> >
> 
> So, you are actually suggesting to move the binary start from the kernel to user-space.
> IOW, you are suggesting to do not using UMH at all.
> Am I right?
> I don't know the reasons, why it was done by using UMH and not in userspace.
> Could you clarify this, Jeff?
> 

nfsdcltrack is a "one-shot" program for managing and querying the nfsd
client tracking database. When knfsd needs to query or modify the
db, it uses the UMH infrastructure to call this program that does
what's requested and then exits.

So, I'm not sure I really understand your question. It wasn't done in
userspace since the whole purpose of this program is to handle upcalls
from the kernel.

-- 
Jeff Layton <jlayton@...hat.com>
--
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/