[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wjeoeh-F-PJmpYRpR_HoiB4r4qYgd3U6igtrUD6q5d_cg@mail.gmail.com>
Date: Tue, 19 May 2020 11:28:14 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Kees Cook <keescook@...omium.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Oleg Nesterov <oleg@...hat.com>, Jann Horn <jannh@...gle.com>,
Greg Ungerer <gerg@...ux-m68k.org>,
Rob Landley <rob@...dley.net>,
Bernd Edlinger <bernd.edlinger@...mail.de>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Alexey Dobriyan <adobriyan@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Casey Schaufler <casey@...aufler-ca.com>,
LSM List <linux-security-module@...r.kernel.org>,
James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Andy Lutomirski <luto@...capital.net>
Subject: Re: [PATCH v2 1/8] exec: Teach prepare_exec_creds how exec treats
uids & gids
On Tue, May 19, 2020 at 11:03 AM Kees Cook <keescook@...omium.org> wrote:
>
> One question, though: why add this, since the repeat calling of the caps
> LSM hook will do this?
I assume it's for the "preserve_creds" case where we don't even end up
setting creds at all.
Yeah, at some point we'll hit a bprm handler that doesn't set
'preserve_creds', and it all does get set in the end, but that's not
statically all that obvious.
I think it makes sense to initialize as much as possible from the
generic code, and rely as little as possible on what the binfmt
handlers end up actually doing.
Linus
Powered by blists - more mailing lists