Re: [PATCH 1/2] wait/ptrace: always assume __WALL if the child is traced

[Oleg Nesterov <oleg@redhat.com>]

On 10/22, Denys Vlasenko wrote:
>
> On Wed, Oct 21, 2015 at 11:47 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> > On 10/21, Denys Vlasenko wrote:
> >>
> >> On 10/21/2015 09:59 PM, Denys Vlasenko wrote:
> >> > On 10/21/2015 12:31 AM, Andrew Morton wrote:
> >> >> Well, to fix this a distro needs to roll out a new kernel.  Or a new
> >> >> init(8).  Is there any reason to believe that distributing/deploying a
> >> >> new kernel is significantly easier for everyone?  Because fixing init
> >> >> sounds like a much preferable solution to this problem.
> >> >
> >> > People will continue to write new init(8) implementations,
> >> > and they will miss this obscure case.
> >> >
> >> > Before this bug was found, it was considered possible to use
> >> > a shell script as init process. What now, every shell needs to add
> >> > __WALL to its waitpids?
> >
> > Why not? I think it can safely use __WALL too.
>
> Because having any userspace program which can happen to be init,
> which includes all shells out there in the wild
> (bash, dash, ash, ksh, zsh, msh, hush,...)
> learn about __WALL is wrong: apart from this wart, they do not have
> to use any Linux-specific code. It can all be perfectly legitimate POSIX.

Yes, this is true. I meant that they could safely use __WALL to, but I
understand that this change can be painful.

> > Sure. But people do the things which were never intended to be
> > used all the time. We simply can not know if this "feature"
> > already has a creative user or not.
>
> It won't be unfixable: they will just have to switch from PTRACE_TRACEME
> to PTRACE_ATTACH.
>
> As of now we do not know any people craz^W creative enough
> to create a cross between init and strace. If such specimens would
> materialize, don't they deserve to have to make that change?

This also applies to people who use bash/whatever as /sbin/init and allow
the untrusted users to run the exploits ;) I do not know who is more crazy.

In any case, the real question is whether we should change the kernel to
fix the problem, or ask the distros to fix their init's. In the former
case 1/2 looks simpler/safer to me than the change in ptrace_traceme(),
and you seem to agree that 1/2 is not that bad.

Oleg.