Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758878Ab3EWMZr (ORCPT ); Thu, 23 May 2013 08:25:47 -0400 Received: from natasha.panasas.com ([67.152.220.90]:34535 "EHLO natasha.panasas.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758158Ab3EWMZp (ORCPT ); Thu, 23 May 2013 08:25:45 -0400 Message-ID: <519E0AB0.7040704@panasas.com> Date: Thu, 23 May 2013 15:25:20 +0300 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Stanislav Kinsbursky CC: Jeff Layton , "Eric W. Biederman" , , , , , , , , , , Subject: Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced 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> In-Reply-To: <519E0474.5000606@parallels.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5275 Lines: 119 On 23/05/13 14:58, Stanislav Kinsbursky wrote: > 23.05.2013 15:56, Jeff Layton пишет: >> On Thu, 23 May 2013 15:38:17 +0400 >> Stanislav Kinsbursky wrote: >> >>> 23.05.2013 15:31, Jeff Layton пишет: >>>> On Thu, 23 May 2013 14:35:53 +0400 >>>> Stanislav Kinsbursky wrote: >>>> >>>>> 23.05.2013 14:00, Eric W. Biederman пишет: >>>>>> Stanislav Kinsbursky writes: >>>>>> >>>>>>> 22.05.2013 21:33, Eric W. Biederman пишет: >>>>>>>> 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 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. >> > > No, I'm just asking to understand. > Eric was, actually, asking the same. I.e. how does NFSd uses UMH and why this can't be done in userspace? > Thanks you for your answer. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/