From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced Date: Thu, 23 May 2013 09:05:26 -0400 Message-ID: <20130523090526.63fc153e@corrin.poochiereds.net> References: <20130522072840.27720.85023.stgit@localhost.localdomain> <878v36ex6n.fsf@xmission.com> <519DCE5D.6070204@parallels.com> <87k3mq9fsu.fsf@xmission.com> <519DF109.9010309@parallels.com> <20130523073108.13afafa6@tlielax.poochiereds.net> <519DFFA9.3010606@parallels.com> <20130523075620.21abf79a@tlielax.poochiereds.net> <519E0474.5000606@parallels.com> <519E0AB0.7040704@panasas.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Stanislav Kinsbursky , "Eric W. Biederman" , , , , , , , , , , To: Boaz Harrosh Return-path: In-Reply-To: <519E0AB0.7040704@panasas.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, 23 May 2013 15:25:20 +0300 Boaz Harrosh wrote: > On 23/05/13 14:58, Stanislav Kinsbursky wrote: > > 23.05.2013 15:56, Jeff Layton =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> On Thu, 23 May 2013 15:38:17 +0400 > >> Stanislav Kinsbursky wrote: > >> > >>> 23.05.2013 15:31, Jeff Layton =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >>>> On Thu, 23 May 2013 14:35:53 +0400 > >>>> Stanislav Kinsbursky wrote: > >>>> > >>>>> 23.05.2013 14:00, Eric W. Biederman =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: > >>>>>> Stanislav Kinsbursky writes: > >>>>>> > >>>>>>> 22.05.2013 21:33, Eric W. Biederman =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: > >>>>>>>> Stanislav Kinsbursky 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 req= uires an ability to > >>>>>>>>> execute a binary in a container's root context. Root swap c= an be done in > >>>>>>>>> "init" callback, passed by UMH caller. > >>>>>>>>> But since we have 2 callers already (and more of them are e= xpected to appear > >>>>>>>>> in future) and because set_fs_root() in not exported, it lo= oks reasonable to > >>>>>>>>> add one more generic UMH helper to generic fs code. > >>>>>>>>> Root path reference must be hold by the caller, since it wi= ll be put on UMH > >>>>>>>>> thread exit. > >>>>>>>> > >>>>>>>> Awesome. With this patch as an uprivilieged user I get to p= ick which > >>>>>>>> binary the kernel will execute. At least if nfs and nfsd ev= er runs in a > >>>>>>>> user namespace (something that looks like only matter of tim= e). > >>>>>>>> > >>>>>>> > >>>>>>> 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 l= ocks 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 t= he 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 c= an enter > >>>>>> into a containers complete context (pid, mnt, root, etc) commi= ng from > >>>>>> the outside. > >>>>>> > >>>>> > >>>>> So, you are actually suggesting to move the binary start from t= he 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 th= e nfsd > >>>> client tracking database. When knfsd needs to query or modify th= e > >>>> db, it uses the UMH infrastructure to call this program that doe= s > >>>> what's requested and then exits. > >>>> > >>>> So, I'm not sure I really understand your question. It wasn't do= ne in > >>>> userspace since the whole purpose of this program is to handle u= pcalls > >>>> from the kernel. > >>>> > >>> > >>> The question is what was the reason to start this binary from ker= nel by UMH? > >> > >> Manipulating and querying the client tracking database is an infre= quent > >> event, so having a continuously running daemon is wasteful and mea= ns > >> that the admin has to ensure that it's running. A UMH upcall is mu= ch > >> 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 th= e only reason why I'm asking. > >>> > >> > >> This program is not a daemon that runs continuously. It's only cal= led > >> 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= =2E > >> > >> In fact, we had that with the nfsdcld program, but no one liked it > >> (including me) for the reasons I detailed above. > >> > >=20 > > No, I'm just asking to understand. > > Eric was, actually, asking the same. I.e. how does NFSd uses UMH an= d why this can't be done in userspace? > > Thanks you for your answer. > >=20 >=20 > I'm not familiar with nfsdcltrack but I would imagine it receives it'= s information from > Kernel as a command line parameters. >=20 > Would it not be the simplest approach to add a --chroot=3D/path/to/ro= ot optional > parameter to nfsdcltrack so it should access an alternate DB relative= to=20 > --chroot. >=20 > This would address Eric's concern of not executing user-privileged ex= ecutable > from Kernel. I think >=20 > Just my $0.017 > Boaz >=20 I think that sounds reasonable. Is it always the case that /path/to/root is reachable from the "primary" namespace? If not, you may need to do something more exotic there. Also, do you have to do anything like change the uid/gid to a different user who is root within the container? 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. --=20 Jeff Layton