[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130820190529.GA24512@redhat.com>
Date: Tue, 20 Aug 2013 21:05:29 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Andy Lutomirski <luto@...capital.net>
Cc: Brad Spengler <spender@...ecurity.net>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Colin Walters <walters@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: PATCH? fix unshare(NEWPID) && vfork()
On 08/20, Andy Lutomirski wrote:
>
> On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov <oleg@...hat.com> wrote:
> >
> >> Currently (with or without your patch), vfork() followed by
> >> unshare(CLONE_NEWUSER) or unshare(CLONE_NEWPID) will unshare the VM.
> >
> > Could you spell please?
> >
> > We never unshare the VM. CLONE_VM in sys_unshare() paths just means
> > "fail unless ->mm is not shared".
> >
>
> Argh. In that case this is probably buggy,
I don't think so. Just we can't really unshare ->mm or implement
unshare(CLONE_THREAD). We simply pretend it works if there is nothing
to unshare.
> sys_unshare will see CLONE_NEWPID or CLONE_NEWUSER and set
> CLONE_THREAD. Then it will see CLONE_THREAD and set CLONE_VM.
This matches copy_process() to some degree... but looks confusing,
I agree.
> Could this be made much more comprehensible by having a single list of
> shareable things are allowed to be shared across namespaces and
> enforcing the *same* list in clone and unshare?
Not sure...
but at least we can probably simplify this a little bit. Say, we can
just kill
if (unshare_flags & CLONE_THREAD)
unshare_flags |= CLONE_VM;
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists