[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87vas4wl3z.fsf@xmission.com>
Date: Tue, 21 Feb 2017 11:30:56 +1300
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Oleg Nesterov <oleg@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Mika Penttilä
<mika.penttila@...tfour.com>, Aleksa Sarai <asarai@...e.com>,
Andy Lutomirski <luto@...capital.net>,
Attila Fazekas <afazekas@...hat.com>,
Jann Horn <jann@...jh.net>, Kees Cook <keescook@...omium.org>,
Michal Hocko <mhocko@...nel.org>,
Ulrich Obergfell <uobergfe@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 1/2] exec: don't wait for zombie threads with cred_guard_mutex held
Oleg,
My apologies for not replying in-line but I think I can be clearer just
saying what I think needs to be said.
Today cred_guard_mutex is part of making exec appear to be an atomic
operation to ptrace and and proc. To make exec appear to be atomic
we do need to take the mutex at the beginning and release it at the end
of exec.
The semantics of exec appear atomic to ptrace_attach and to proc readers
are necessary to ensure we use the proper process credentials in the
event of a suid exec.
I believe making cred_guard_mutex per task is an option. Reducing the
scope of cred_guard_mutex concerns me. There appear to be some fields
like sighand that we currently expose in proc that might possibly be
problematic. So I am not certain we protect enough things in our proc
accessors.
Do you know if we can make cred_guard_mutex a per-task lock again?
Eric
Powered by blists - more mailing lists