Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758684Ab3EWLbY (ORCPT ); Thu, 23 May 2013 07:31:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63192 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758432Ab3EWLbV convert rfc822-to-8bit (ORCPT ); Thu, 23 May 2013 07:31:21 -0400 Date: Thu, 23 May 2013 07:31:08 -0400 From: Jeff Layton To: Stanislav Kinsbursky Cc: "Eric W. Biederman" , , , , , , , , , , , Subject: Re: [RFC PATCH] fs: call_usermodehelper_root helper introduced Message-ID: <20130523073108.13afafa6@tlielax.poochiereds.net> In-Reply-To: <519DF109.9010309@parallels.com> References: <20130522072840.27720.85023.stgit@localhost.localdomain> <878v36ex6n.fsf@xmission.com> <519DCE5D.6070204@parallels.com> <87k3mq9fsu.fsf@xmission.com> <519DF109.9010309@parallels.com> Mime-Version: 1.0 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: 3262 Lines: 76 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. -- Jeff Layton -- 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/