All of lore.kernel.org
 help / color / mirror / Atom feed
From: Serge Hallyn <serge.hallyn@ubuntu.com>
To: Oleg Nesterov <oleg@redhat.com>, Christian Seiler <christian@iwakd.de>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Andy Whitcroft <apw@canonical.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Lxc development list <lxc-devel@lists.sourceforge.net>
Subject: CLONE_PARENT after setns(CLONE_NEWPID)
Date: Wed, 6 Nov 2013 12:02:32 -0600	[thread overview]
Message-ID: <20131106180232.GA8980@ac100> (raw)

Hi Oleg,

commit 40a0d32d1eaffe6aac7324ca92604b6b3977eb0e :
"fork: unify and tighten up CLONE_NEWUSER/CLONE_NEWPID checks"
breaks lxc-attach in 3.12.  That code forks a child which does
setns() and then does a clone(CLONE_PARENT).  That way the
grandchild can be in the right namespaces (which the child was
not) and be a child of the original task, which is the monitor.

lxc-attach in 3.11 was working fine with no side effects that I
could see.  Is there a real danger in allowing CLONE_PARENT
when current->nsproxy->pidns_for_children is not our pidns,
or was this done out of an "over-abundance of caution"?  Can we
safely revert that new extra check?

thanks,
-serge

             reply	other threads:[~2013-11-06 18:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06 18:02 Serge Hallyn [this message]
2013-11-06 19:33 ` CLONE_PARENT after setns(CLONE_NEWPID) Oleg Nesterov
2013-11-06 19:50   ` Andy Lutomirski
2013-11-06 20:06     ` Oleg Nesterov
2013-11-06 20:21       ` Andy Lutomirski
2013-11-06 22:50   ` Eric W. Biederman
2013-11-06 22:56     ` Andy Lutomirski
2013-11-06 23:17       ` Serge Hallyn
2013-11-06 23:12     ` Serge Hallyn
2013-11-06 23:31     ` Christian Seiler
2013-11-08 17:22     ` Oleg Nesterov
2014-01-15 21:11     ` Christian Seiler
2014-01-16  4:46       ` Serge Hallyn
2013-11-06 22:53   ` Serge Hallyn
2013-11-06 22:53     ` Eric W. Biederman

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=20131106180232.GA8980@ac100 \
    --to=serge.hallyn@ubuntu.com \
    --cc=apw@canonical.com \
    --cc=christian@iwakd.de \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lxc-devel@lists.sourceforge.net \
    --cc=oleg@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.