Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755284AbbBHPWQ (ORCPT ); Sun, 8 Feb 2015 10:22:16 -0500 Received: from mail-qa0-f50.google.com ([209.85.216.50]:47459 "EHLO mail-qa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751340AbbBHPWO (ORCPT ); Sun, 8 Feb 2015 10:22:14 -0500 Date: Sun, 8 Feb 2015 10:22:10 -0500 From: Jeff Layton To: Ian Kent Cc: Kernel Mailing List , David Howells , Oleg Nesterov , Trond Myklebust , "J. Bruce Fields" , Benjamin Coddington , Al Viro , "Eric W. Biederman" Subject: Re: [RFC PATCH 3/8] kmod - teach call_usermodehelper() to use a namespace Message-ID: <20150208102210.53aa066f@tlielax.poochiereds.net> In-Reply-To: <1423364852.2641.2.camel@pluto.fritz.box> References: <20150205021553.8382.16297.stgit@pluto.fritz.box> <20150205023410.8382.13695.stgit@pluto.fritz.box> <20150206070859.7eb499b0@tlielax.poochiereds.net> <1423364852.2641.2.camel@pluto.fritz.box> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5252 Lines: 131 On Sun, 08 Feb 2015 11:07:32 +0800 Ian Kent wrote: > On Fri, 2015-02-06 at 07:08 -0500, Jeff Layton wrote: > > On Thu, 05 Feb 2015 10:34:11 +0800 > > Ian Kent wrote: > > > > > The call_usermodehelper() function executes all binaries in the > > > global "init" root context. This doesn't allow a binary to be run > > > within a namespace (eg. the namespace of a container). > > > > > > Both containerized NFS client and NFS server need the ability to > > > execute a binary in a container's context. To do this use the init > > > process of the callers environment is used to setup the namespaces > > > in the same way the root init process is used otherwise. > > > > > > Signed-off-by: Ian Kent > > > Cc: Benjamin Coddington > > > Cc: Al Viro > > > Cc: J. Bruce Fields > > > Cc: David Howells > > > Cc: Trond Myklebust > > > Cc: Oleg Nesterov > > > Cc: Eric W. Biederman > > > Cc: Jeff Layton > > > --- > > > include/linux/kmod.h | 16 +++++++ > > > kernel/kmod.c | 115 +++++++++++++++++++++++++++++++++++++++++++++++++- > > > 2 files changed, 128 insertions(+), 3 deletions(-) > > > > > > diff --git a/include/linux/kmod.h b/include/linux/kmod.h > > > index 15bdeed..b0f1b3c 100644 > > > --- a/include/linux/kmod.h > > > +++ b/include/linux/kmod.h > > > @@ -52,6 +52,7 @@ struct file; > > > #define UMH_WAIT_EXEC 1 /* wait for the exec, but not the process */ > > > #define UMH_WAIT_PROC 2 /* wait for the process to complete */ > > > #define UMH_KILLABLE 4 /* wait for EXEC/PROC killable */ > > > +#define UMH_USE_NS 8 /* exec using caller's init namespace */ > > > > > > struct subprocess_info { > > > struct work_struct work; > > > @@ -69,6 +70,21 @@ struct subprocess_info { > > > extern int > > > call_usermodehelper(char *path, char **argv, char **envp, int flags); > > > > > > +#if !defined(CONFIG_PROC_FS) || !defined(CONFIG_NAMESPACES) > > > +inline struct task_struct *umh_get_init_task(void) > > > +{ > > > + return ERR_PTR(-ENOTSUP); > > > +} > > > + > > > +inline int umh_enter_ns(struct task_struct *tsk, struct cred *new) > > > +{ > > > + return -ENOTSUP; > > > +} > > > +#else > > > +struct task_struct *umh_get_init_pid(void); > > > +int umh_enter_ns(struct task_struct *tsk, struct cred *new); > > > +#endif > > > + > > > extern struct subprocess_info * > > > call_usermodehelper_setup(char *path, char **argv, char **envp, gfp_t gfp_mask, > > > int (*init)(struct subprocess_info *info, struct cred *new), > > > diff --git a/kernel/kmod.c b/kernel/kmod.c > > > index 14c0188..4c649d6 100644 > > > --- a/kernel/kmod.c > > > +++ b/kernel/kmod.c > > > @@ -582,6 +582,98 @@ unlock: > > > } > > > EXPORT_SYMBOL(call_usermodehelper_exec); > > > > > > +#if defined(CONFIG_PROC_FS) && defined(CONFIG_NAMESPACES) > > > +#define NS_PATH_MAX 35 > > > +#define NS_PATH_FMT "%lu/ns/%s" > > > + > > > +/* Note namespace name order is significant */ > > > +static const char *ns_names[] = { "user", "ipc", "uts", "net", "pid", "mnt", NULL }; > > > + > > > +struct task_struct *umh_get_init_pid(void) > > > > nit: we're not getting a pid here but a task_struct pointer. Maybe this > > should be called umh_get_init_task? > > Ha, yep. > > > > > > +{ > > > + struct task_struct *tsk; > > > + > > > + rcu_read_lock(); > > > + tsk = find_task_by_vpid(1); > > > + if (tsk) > > > + get_task_struct(tsk); > > > + rcu_read_unlock(); > > > > I'm not terribly familiar with the task_struct lifetime rules... > > > > I assume that you can be assured that tsk won't go away while you hold > > the rcu_read_lock, but is doing a get_task_struct while holding it > > sufficient to pin it after you drop the lock? > > > > IOW, could the refcount on the task_struct do a 0->1 transition here and > > end up being freed anyway after you've grabbed a reference? > > Good point, I thought getting a reference under he read lock would be > enough but maybe I need more checks as I do with dentrys. I'll check > that. > It looks like the rcu_read_lock is mostly there to protect the pid_hash actually, and get_pid_task seems to do something very similar here. So, I think you're probably fine to do what you're doing in this patch. That said, the "What is struct pid?" comments in include/linux/pid.h are interesting. I wonder if my comments on your original patch were actually unfounded. If you hold a reference to a pid_t, that might be enough to ensure that it doesn't get reused, but I'm not sure at that point if it could end up being detached from the task. I suspect that pinning the actual task like you're doing here is probably the right thing to do, but I'd certainly value input from someone who understands the task/pid interaction better than I do. -- 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/