[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wi03QRcUR1DfbEr+Pw-DAMENzY-FuRcGawtj9p597=p2w@mail.gmail.com>
Date: Tue, 28 Apr 2020 13:35:41 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Jann Horn <jannh@...gle.com>,
Bernd Edlinger <bernd.edlinger@...mail.de>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
Waiman Long <longman@...hat.com>,
Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alexey Gladkov <gladkov.alexey@...il.com>
Subject: Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1
On Tue, Apr 28, 2020 at 12:08 PM Oleg Nesterov <oleg@...hat.com> wrote:
>
> Oops. I can update that old patch but somehow I thought there is a better
> plan which I don't yet understand...
I don't think any plan survived reality.
Unless we want to do something *really* hacky.. The attached patch is
not meant to be serious.
> And, IIRC, Jan had some ideas how to rework the new creds calculation in
> execve paths to avoid the cred_guard_mutex deadlock?
I'm not sure how you'd do that.
Execve() fundamentally needs to serialize with PTRACE_ATTACH somehow,
since the whole point is that "tsk->ptrace" changes how the
credentials are interpreted.
So PTRACE_ATTACH doesn't really _change_ the credentials, but it very
much changes what execve() will do with them.
But I guess we could do a "if somebody attached to us while we did the
execve(), just repeat the whole thing"
Jann, what was your clever idea? Maybe it got lost in the long thread..
Linus
Download attachment "patch" of type "application/octet-stream" (1319 bytes)
Powered by blists - more mailing lists