[PATCH 3/5] exec: Remove recursion from search_binary_handler
keescook at chromium.org
Tue May 12 23:08:56 UTC 2020
On Tue, May 12, 2020 at 03:31:57PM -0500, Eric W. Biederman wrote:
> >> It is possible although unlikely for userspace to find the file
> >> descriptor without consulting AT_EXECFD so just to be conservative I
> >> think we should install the file descriptor in begin_new_exec even if
> >> the next interpreter does not support AT_EXECFD.
> > I think universally installing the fd needs to be a distinct patch --
> > it's going to have a lot of consequences, IMO. We can certainly deal
> > with them, but I don't think it should be part of this clean-up series.
> I meant generically installing the fd not universally installing it.
> >> I am still working on how to handle recursive binfmts but I suspect it
> >> is just a matter of having an array of struct files in struct
> >> linux_binprm.
> > If install is left if binfmt_misc, then the recursive problem goes away,
> > yes?
> I don't think leaving the install in binfmt_misc is responsible at this
I'm nearly certain the answer is "yes", but I wonder if we should stop
for a moment and ask "does anything still use MISC_FMT_OPEN_BINARY ? It
looks like either "O" or "C" binfmt_misc registration flag. My installed
binfmts on Ubuntu don't use them...
I'm currently pulling a list of all the packages in Debian than depend
on the binfmt-support package and checking their flags.
More information about the Linux-security-module-archive