On 08/21, Oleg Nesterov wrote:
>
> Still. Can't we make a single check? Like the initial patch I sent, but
> this one moves the check into copy_process() and checks CLONE_* first.
> Looks a bit simpler. And more understandable to me but this is subjective.
Seriously. CLONE_NEWPID and
On 08/21, Oleg Nesterov wrote:
Still. Can't we make a single check? Like the initial patch I sent, but
this one moves the check into copy_process() and checks CLONE_* first.
Looks a bit simpler. And more understandable to me but this is subjective.
Seriously. CLONE_NEWPID and
On 08/20, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> >>
> >> The patch below also needs CLONE_SIGHAND. You can't meaningfully share
> >> signal handlers if you can't represent the pid in the siginfo. pids and
> >> signals are too interconnected.
> >
> > I don't really understand. If
On 08/20, Andy Lutomirski wrote:
>
> On Tue, Aug 20, 2013 at 12:23 PM, Oleg Nesterov wrote:
> >
> >> but vfork(); unshare(CLONE_NEWPID) will fail? (I
> >> admit I haven't tested it.)
> >
> > Do you mean that the child does unshare(CLONE_NEWPID) before exec?
> > It should fail with or without
On 08/20, Andy Lutomirski wrote:
On Tue, Aug 20, 2013 at 12:23 PM, Oleg Nesterov o...@redhat.com wrote:
but vfork(); unshare(CLONE_NEWPID) will fail? (I
admit I haven't tested it.)
Do you mean that the child does unshare(CLONE_NEWPID) before exec?
It should fail with or without this
On 08/20, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
The patch below also needs CLONE_SIGHAND. You can't meaningfully share
signal handlers if you can't represent the pid in the siginfo. pids and
signals are too interconnected.
I don't really understand. If we
Oleg Nesterov writes:
> On 08/20, Eric W. Biederman wrote:
>>
>> Oleg Nesterov writes:
>>
>> > On 08/19, Andy Lutomirski wrote:
>> >>
>> >> On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov wrote:
>> >> >
>> >> > So do you think this change is fine or not (ignoring the fact it needs
>> >> >
Andy Lutomirski writes:
> On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov wrote:
>> On 08/20, Andy Lutomirski wrote:
>>>
>>> On Mon, Aug 19, 2013 at 11:43 AM, Oleg Nesterov wrote:
>>> > On 08/19, Andy Lutomirski wrote:
>>> >>
>>> >> On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov wrote:
>>>
On Tue, Aug 20, 2013 at 12:23 PM, Oleg Nesterov wrote:
> On 08/20, Andy Lutomirski wrote:
>>
>> On Tue, Aug 20, 2013 at 12:05 PM, Oleg Nesterov wrote:
>> > On 08/20, Andy Lutomirski wrote:
>> Huh? Doesn't this mean that unshare(CLONE_NEWPID); vfork() will work
>> with your patches,
>
> I hope,
On 08/20, Andy Lutomirski wrote:
>
> On Tue, Aug 20, 2013 at 12:05 PM, Oleg Nesterov wrote:
> > On 08/20, Andy Lutomirski wrote:
> >>
> >> On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov wrote:
> >> >
> >> >> Currently (with or without your patch), vfork() followed by
> >> >>
On Tue, Aug 20, 2013 at 12:05 PM, Oleg Nesterov wrote:
> On 08/20, Andy Lutomirski wrote:
>>
>> On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov wrote:
>> >
>> >> Currently (with or without your patch), vfork() followed by
>> >> unshare(CLONE_NEWUSER) or unshare(CLONE_NEWPID) will unshare the VM.
On 08/20, Andy Lutomirski wrote:
>
> On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov 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
On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov wrote:
> On 08/20, Andy Lutomirski wrote:
>>
>> On Mon, Aug 19, 2013 at 11:43 AM, Oleg Nesterov wrote:
>> > On 08/19, Andy Lutomirski wrote:
>> >>
>> >> On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov wrote:
>> >> >
>> >> > So do you think this
On 08/20, Andy Lutomirski wrote:
>
> On Mon, Aug 19, 2013 at 11:43 AM, Oleg Nesterov wrote:
> > On 08/19, Andy Lutomirski wrote:
> >>
> >> On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov wrote:
> >> >
> >> > So do you think this change is fine or not (ignoring the fact it needs
> >> > cleanups)
On 08/20, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
>
> > On 08/19, Andy Lutomirski wrote:
> >>
> >> On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov wrote:
> >> >
> >> > So do you think this change is fine or not (ignoring the fact it needs
> >> > cleanups) ?
> >>
> >> I think that
On Mon, Aug 19, 2013 at 11:43 AM, Oleg Nesterov wrote:
> On 08/19, Andy Lutomirski wrote:
>>
>> On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov wrote:
>> >
>> > So do you think this change is fine or not (ignoring the fact it needs
>> > cleanups) ?
>>
>> I think that removing the CLONE_VM check
Oleg Nesterov writes:
> On 08/19, Andy Lutomirski wrote:
>>
>> On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov wrote:
>> >
>> > So do you think this change is fine or not (ignoring the fact it needs
>> > cleanups) ?
>>
>> I think that removing the CLONE_VM check is fine (although there are
>>
Oleg Nesterov o...@redhat.com writes:
On 08/19, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov o...@redhat.com wrote:
So do you think this change is fine or not (ignoring the fact it needs
cleanups) ?
I think that removing the CLONE_VM check is fine (although
On Mon, Aug 19, 2013 at 11:43 AM, Oleg Nesterov o...@redhat.com wrote:
On 08/19, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov o...@redhat.com wrote:
So do you think this change is fine or not (ignoring the fact it needs
cleanups) ?
I think that removing the
On 08/20, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
On 08/19, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov o...@redhat.com wrote:
So do you think this change is fine or not (ignoring the fact it needs
cleanups) ?
I think that
On 08/20, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 11:43 AM, Oleg Nesterov o...@redhat.com wrote:
On 08/19, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov o...@redhat.com wrote:
So do you think this change is fine or not (ignoring the fact it needs
On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov o...@redhat.com wrote:
On 08/20, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 11:43 AM, Oleg Nesterov o...@redhat.com wrote:
On 08/19, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov o...@redhat.com wrote:
So
On 08/20, Andy Lutomirski wrote:
On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov o...@redhat.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.
On Tue, Aug 20, 2013 at 12:05 PM, Oleg Nesterov o...@redhat.com wrote:
On 08/20, Andy Lutomirski wrote:
On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov o...@redhat.com wrote:
Currently (with or without your patch), vfork() followed by
unshare(CLONE_NEWUSER) or unshare(CLONE_NEWPID) will
On 08/20, Andy Lutomirski wrote:
On Tue, Aug 20, 2013 at 12:05 PM, Oleg Nesterov o...@redhat.com wrote:
On 08/20, Andy Lutomirski wrote:
On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov o...@redhat.com wrote:
Currently (with or without your patch), vfork() followed by
On Tue, Aug 20, 2013 at 12:23 PM, Oleg Nesterov o...@redhat.com wrote:
On 08/20, Andy Lutomirski wrote:
On Tue, Aug 20, 2013 at 12:05 PM, Oleg Nesterov o...@redhat.com wrote:
On 08/20, Andy Lutomirski wrote:
Huh? Doesn't this mean that unshare(CLONE_NEWPID); vfork() will work
with your
Andy Lutomirski l...@amacapital.net writes:
On Tue, Aug 20, 2013 at 11:50 AM, Oleg Nesterov o...@redhat.com wrote:
On 08/20, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 11:43 AM, Oleg Nesterov o...@redhat.com wrote:
On 08/19, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 11:33 AM,
Oleg Nesterov o...@redhat.com writes:
On 08/20, Eric W. Biederman wrote:
Oleg Nesterov o...@redhat.com writes:
On 08/19, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov o...@redhat.com wrote:
So do you think this change is fine or not (ignoring the fact it
On 08/19, Andy Lutomirski wrote:
>
> On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov wrote:
> >
> > So do you think this change is fine or not (ignoring the fact it needs
> > cleanups) ?
>
> I think that removing the CLONE_VM check is fine (although there are
> some other ones that should
On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov wrote:
> On 08/19, Andy Lutomirski wrote:
>>
>> On Mon, Aug 19, 2013 at 10:25 AM, Oleg Nesterov wrote:
>> > Hello.
>> >
>> > Colin reports that vfork() doesn't work after unshare(PIDNS). The
>> > reason is trivial, copy_process() does:
>> >
>> >
On 08/19, Andy Lutomirski wrote:
>
> On Mon, Aug 19, 2013 at 10:25 AM, Oleg Nesterov wrote:
> > Hello.
> >
> > Colin reports that vfork() doesn't work after unshare(PIDNS). The
> > reason is trivial, copy_process() does:
> >
> > /*
> > * If the new process will be in a different
On Mon, Aug 19, 2013 at 10:25 AM, Oleg Nesterov wrote:
> Hello.
>
> Colin reports that vfork() doesn't work after unshare(PIDNS). The
> reason is trivial, copy_process() does:
>
> /*
> * If the new process will be in a different pid namespace
> * don't allow the creation
On 08/19, Linus Torvalds wrote:
>
> So I think your patch is correct, although I'm not sure why you move
> the test.
I didn't really, we have 2 tests, in do_fork() and copy_process().
I think it would be better to do the similar checks in one place.
This is off-topic and needs a separate change
On Mon, Aug 19, 2013 at 10:25 AM, Oleg Nesterov wrote:
>
> Colin reports that vfork() doesn't work after unshare(PIDNS). The
> reason is trivial, copy_process() does:
>
> /*
> * If the new process will be in a different pid namespace
> * don't allow the creation of
Hello.
Colin reports that vfork() doesn't work after unshare(PIDNS). The
reason is trivial, copy_process() does:
/*
* If the new process will be in a different pid namespace
* don't allow the creation of threads.
*/
if ((clone_flags &
Hello.
Colin reports that vfork() doesn't work after unshare(PIDNS). The
reason is trivial, copy_process() does:
/*
* If the new process will be in a different pid namespace
* don't allow the creation of threads.
*/
if ((clone_flags
On Mon, Aug 19, 2013 at 10:25 AM, Oleg Nesterov o...@redhat.com wrote:
Colin reports that vfork() doesn't work after unshare(PIDNS). The
reason is trivial, copy_process() does:
/*
* If the new process will be in a different pid namespace
* don't allow the creation
On 08/19, Linus Torvalds wrote:
So I think your patch is correct, although I'm not sure why you move
the test.
I didn't really, we have 2 tests, in do_fork() and copy_process().
I think it would be better to do the similar checks in one place.
This is off-topic and needs a separate change
On Mon, Aug 19, 2013 at 10:25 AM, Oleg Nesterov o...@redhat.com wrote:
Hello.
Colin reports that vfork() doesn't work after unshare(PIDNS). The
reason is trivial, copy_process() does:
/*
* If the new process will be in a different pid namespace
* don't allow the
On 08/19, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 10:25 AM, Oleg Nesterov o...@redhat.com wrote:
Hello.
Colin reports that vfork() doesn't work after unshare(PIDNS). The
reason is trivial, copy_process() does:
/*
* If the new process will be in a different
On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov o...@redhat.com wrote:
On 08/19, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 10:25 AM, Oleg Nesterov o...@redhat.com wrote:
Hello.
Colin reports that vfork() doesn't work after unshare(PIDNS). The
reason is trivial, copy_process() does:
On 08/19, Andy Lutomirski wrote:
On Mon, Aug 19, 2013 at 11:33 AM, Oleg Nesterov o...@redhat.com wrote:
So do you think this change is fine or not (ignoring the fact it needs
cleanups) ?
I think that removing the CLONE_VM check is fine (although there are
some other ones that should
42 matches
Mail list logo