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 07:56:20 -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 15:38:17 +0400
Stanislav Kinsbursky <skinsbursky@...allels.com> wrote:

> 23.05.2013 15:31, Jeff Layton пишет:
> > 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.
> >
> 
> The question is what was the reason to start this binary from kernel by UMH?

Manipulating and querying the client tracking database is an infrequent
event, so having a continuously running daemon is wasteful and means
that the admin has to ensure that it's running. A UMH upcall is much
simpler and generally "just works" if the program is present.

> I.e. why it can't be started by some user-space process before or after NFSd start?
> I don't familiar with this client tracking facility and that's the only reason why I'm asking.
> 

This program is not a daemon that runs continuously. It's only called
when the kernel needs to manipulate the database. Are you asking
whether we could turn this into a continuously running daemon? If so
then the answer is "yes", but that's not really a good idea either.

In fact, we had that with the nfsdcld program, but no one liked it
(including me) for the reasons I detailed above.

-- 
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/