Re: [PATCH v6 5/6] binfmt_*: scope path resolution of interpreters
From: Christian Brauner <christian@brauner.io>
Date: 2019-05-11 17:49:05
Also in:
linux-arch, linux-fsdevel, lkml
From: Christian Brauner <christian@brauner.io>
Date: 2019-05-11 17:49:05
Also in:
linux-arch, linux-fsdevel, lkml
On May 11, 2019 7:43:44 PM GMT+02:00, Linus Torvalds [off-list ref] wrote:
On Sat, May 11, 2019 at 1:31 PM Aleksa Sarai [off-list ref] wrote:quoted
Yup, I've dropped the patch for the next version. (To be honest, I'mnotquoted
sure why I included any of the other flags -- the only one thatwould'vequoted
been necessary to deal with CVE-2019-5736 was AT_NO_MAGICLINKS.)I do wonder if we could try to just set AT_NO_MAGICLINKS unconditionally for execve() (and certainly for the suid case). I'd rather try to do these things across the board, than have "suid binaries are treated specially" if at all possible. The main use case for having /proc/<pid>/exe thing is for finding open file descriptors, and for 'ps' kind of use, or to find the startup directory when people don't populate the execve() environment fully (ie "readlink(/proc/self/exe)" is afaik pretty common. Sadly, googling for execve /proc/self/exe does actually find hits, including one that implies that chrome does exactly that. So it might not be possible. Somewhat odd, but it does just confirm the whole "users will at some point do everything in their power to use every odd special case, intended or not". Linus
Sadly I have to admit that we are using this. Also, execveat on glibc is implemented via /proc/self/fd/<nr> on kernels that do not have a proper execveat. See fexecve... Christian