[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgy_e1OY=OoPXp+4ZGEsYmRVQW8c_0GPYT-HfK376MKqA@mail.gmail.com>
Date: Wed, 8 Apr 2020 10:25:17 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Bernd Edlinger <bernd.edlinger@...mail.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alexey Gladkov <gladkov.alexey@...il.com>,
Oleg Nesterov <oleg@...hat.com>,
Kees Cook <keescook@...omium.org>,
Jann Horn <jannh@...gle.com>,
Christian Brauner <christian.brauner@...ntu.com>
Subject: Re: [PATCH 1/3] binfmt: Move install_exec_creds after setup_new_exec
to match binfmt_elf
On Mon, Apr 6, 2020 at 6:34 PM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> In 2016 Linus moved install_exec_creds immediately after
> setup_new_exec, in binfmt_elf as a cleanup and as part of closing a
> potential information leak.
>
> Perform the same cleanup for the other binary formats
Can we not move it _into_ setup_new_exec() now if you've changed all
the binfmt handlers?
The fewer cases of "this gets called by the low-level handler at
different points" that we have, the better off we'd be, I think. One
of the complexities of our execve() code is that some of it gets
called directly, and some of it gets called by the binfmt handler, and
it's often very hard to see the logic when it jumps out to the binfmt
code and then back to the generic fs/exec.c code..
Linus
Powered by blists - more mailing lists