public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ian Kent <ikent@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Stanislav Kinsbursky <skinsbursky@parallels.com>,
	Trond Myklebust <trond.myklebust@primarydata.com>,
	David Howells <dhowells@redhat.com>,
	Benjamin Coddington <bcodding@redhat.com>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Subject: Re: [RFC PATCH 3/4] kmod - add call_usermodehelper_ns() helper
Date: Wed, 26 Nov 2014 06:36:07 +0800	[thread overview]
Message-ID: <1416954967.2509.25.camel@pluto.fritz.box> (raw)
In-Reply-To: <20141125215248.GA7958@redhat.com>

On Tue, 2014-11-25 at 22:52 +0100, Oleg Nesterov wrote:
> Let me first apologize, I didn't actually read this series yet.
> 
> But I have to admit that so far I do not like this approach...
> probably I am biased.

Oleg, thanks for your comments.

> 
> On 11/25, 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 the callers namespace (aka. a container).
> 
> Please see below.
> 
> > Both containerized NFS client and NFS server need the ability to
> > execute a binary within their container. To do this create a new
> > nsproxy within the callers' context so it can be used for setup
> > prior to calling do_execve() from the user mode helper thread
> > runner.
> 
> and probably we also need this for coredump helpers, we want them
> to be per-namespace.

To save me some time could you point me to some of the related code
please. I don't normally play in that area.

> 
> > +static int umh_set_ns(struct subprocess_info *info, struct cred *new)
> > +{
> > +	struct nsproxy *ns = info->data;
> > +
> > +	mntns_setfs(ns->mnt_ns);
> 
> Firstly, it is not clear to me if we should use the caller's ->mnt_ns.
> Let me remind about the coredump. The dumping task can cloned with
> CLONE_NEWNS or it cam do unshare(NEWNS)... but OK, I do not understand
> this enough.
> 
> 
> > +	switch_task_namespaces(current, ns);
> 
> This doesn't look sane because this won't switch task_active_pid_ns().

I wondered about that too but I didn't design the open()/setns()
interface and TBH I've been wondering how he hell it is supposed to work
because of exactly this.

The statement amounts to saying that the
fd = open(/proc/<pid in target namespace>/ns/mnt);
setns(fd);
won't set the namespace properly but the documentation I've seen so far
(there's probably more that I need to see, I'll look further) implies
this is sufficient.

How does one correctly set the namespace in user space since each of
the /proc/<pid>/ns/<namespace> will use a slightly different
proc_ns_operations install function? 

Are we saying that, for example, if open(/proc/<pid>/ns/pid)/setns() is
used then the process must not do path lookups if it expects them to be
within the namespace and restrict itself to pid related system calls
only and so on for each of the other namespaces?

Or is it assumed that userspace will do
open(/proc/<pid>/ns/<namespace>)/setns()/close() every time it makes
systems calls that rely on a specific type of namespace?

> 
> And this reminds me another discussion, please look at
> http://marc.info/?l=linux-kernel&m=138479570926192
> 
> Once again, this is just an idea to provoke more discussion. I am starting
> to think that perhaps we need pid_ns->umh_helper (init by default). And
> PR_SET_NS_UMH_HELPER.

Yeah, I'll need to digest that for a while.

Ian


  parent reply	other threads:[~2014-11-25 22:36 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-25  1:07 [RFC PATCH 0/4] Namespace contrained helper execution Ian Kent
2014-11-25  1:07 ` [RFC PATCH 1/4] vfs - fs/namespaces.c: break out mntns_setfs() from mntns_install() Ian Kent
2014-11-25  1:07 ` [RFC PATCH 2/4] nsproxy - make create_new_namespaces() non-static Ian Kent
2014-11-25  1:07 ` [RFC PATCH 3/4] kmod - add call_usermodehelper_ns() helper Ian Kent
2014-11-25 21:52   ` Oleg Nesterov
2014-11-25 22:06     ` Oleg Nesterov
2014-11-25 22:23       ` Eric W. Biederman
2014-11-25 23:07         ` Ian Kent
2014-11-25 23:19           ` Eric W. Biederman
2014-11-25 23:50             ` Ian Kent
2014-11-26  0:44               ` Ian Kent
2014-11-26  1:38               ` Eric W. Biederman
2014-12-01 21:56                 ` Benjamin Coddington
2014-12-02 23:33                   ` Ian Kent
2014-12-03 16:49                     ` Eric W. Biederman
2014-12-03 18:14                       ` Benjamin Coddington
2014-12-03 22:53                       ` Ian Kent
2014-12-03 23:34                       ` Ian Kent
2014-11-26 11:46         ` David Howells
2014-11-26 15:00           ` Eric W. Biederman
2014-11-26 22:57             ` J. Bruce Fields
2014-11-25 23:14       ` Ian Kent
2014-11-25 22:36     ` Ian Kent [this message]
2014-11-25 23:27       ` Eric W. Biederman
2014-11-28  0:19         ` Ian Kent
2014-11-27  1:30       ` Oleg Nesterov
2014-11-25  1:07 ` [RFC PATCH 4/4] KEYS: exec request-key within the requesting task's namespace Ian Kent

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1416954967.2509.25.camel@pluto.fritz.box \
    --to=ikent@redhat.com \
    --cc=bcodding@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=skinsbursky@parallels.com \
    --cc=trond.myklebust@primarydata.com \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox