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 > point. 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. -- Kees Cook
