Messages in this thread | | | Subject | Re: [PATCH 3/5] exec: Remove recursion from search_binary_handler | From | Rob Landley <> | Date | Tue, 12 May 2020 21:39:29 -0500 |
| |
On 5/12/20 7:20 PM, Linus Torvalds wrote: > On Tue, May 12, 2020 at 11:46 AM Eric W. Biederman > <ebiederm@xmission.com> wrote: >> >> I am still thinking about this one, but here is where I am at. At a >> practical level passing the file descriptor of the script to interpreter >> seems like something we should encourage in the long term. It removes >> races and it is cheaper because then the interpreter does not have to >> turn around and open the script itself. > > Yeah, I think we should continue to support it, because I think it's > the right thing to do (and we might just end up having compatibility > issues if we don't). ... >> 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. > > Ack. I think the AT_EXECFD thing is a sign that this isn't internal to > binfmt_misc, but it also shouldn't be gating this issue. In reality, > ELF is the only real binary format that matters - the script/misc > binfmts are just indirection entries - and it supports AT_EXECFD, so > let's just ignore the theoretical case of "maybe nobody exposes it".
Would this potentially make the re-exec-yourself case easier to do at some point? (Which nommu needs to do, and /proc/self/exe isn't always available.)
Here's the first time I asked about that:
https://lore.kernel.org/lkml/200612261823.07927.rob@landley.net/
Here's the most recent:
https://lkml.org/lkml/2017/9/5/246
Here's someone else asking and being basically told "chroot isn't a thing":
http://lkml.iu.edu/hypermail/linux/kernel/0906.3/00584.html
(See also "CVE-2019-5736" and the workarounds thereto.)
Rob
P.S. Yes I'm aware it would only work properly with static binaries. Not the first thing that's true for.
| |