[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874ktd6jl4.fsf@x220.int.ebiederm.org>
Date: Tue, 21 Apr 2020 08:42:47 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Christian Brauner <christian.brauner@...ntu.com>
Cc: Oleg Nesterov <oleg@...hat.com>,
Linux Containers <containers@...ts.linux-foundation.org>,
Christof Meerwald <cmeerw@...erw.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] signal: Avoid corrupting si_pid and si_uid in do_notify_parent
Christian Brauner <christian.brauner@...ntu.com> writes:
> On Tue, Apr 21, 2020 at 02:17:22PM +0200, Oleg Nesterov wrote:
>> On 04/21, Christian Brauner wrote:
>> >
>> > process B setnses into
>> > <pidnsC> which is a sibling pid namespace,
>>
>> please see pidns_install(), it verifies that
>>
>> * Only allow entering the current active pid namespace
>> * or a child of the current active pid namespace.
>
> I forgot about that.
>
> Though, don't we have the same problem in:
>
> static void do_notify_parent_cldstop(struct task_struct *tsk,
> bool for_ptracer, int why)
>
> at least for the for_ptrace is false case?
The same problem does not exist with do_notify_parent_cldstop because
do_notify_parent_cldstop is always called from current (there is
one case of current->group_leader but that is close enough calculations
made against current are true).
However because do_notify_parent_cldstop calculates si_pid and si_uid of
the target parent process I think we can still get the wrong si_uid.
So it probably makes sense to generalize the fixup code in send_signal
and make do_notify_parent_cldstop just generate ids in the current
namespace and let the fixup code do it's job.
Eric
Powered by blists - more mailing lists