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

[Denys Vlasenko]

On Wed, Oct 21, 2015 at 11:47 PM, Oleg Nesterov <oleg@xxxxxxxxxx> 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.

>> > The use of PTRACE_TRACEME in this reproducer is clearly pathological:
>> > PTRACE_TRACEME was never intended to be used to attach to unsuspecting
>> > processes.
>
> 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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/