On Fri, 2016-08-26 at 13:59 -0400, Carlos O'Donell wrote: > On 08/26/2016 10:55 AM, Florian Weimer wrote: > > On 08/25/2016 06:15 PM, James Bottomley wrote: > > > On Sun, 2016-08-21 at 21:01 -0700, Josh Max wrote: > > > > This patch allows binfmt_misc to select the interpeter for > > > > arbitrary binaries by comparing a specified registered keyword > > > > with the value of a specified binary's extended attribute > > > > (user.binfmt.interp), and then launching the program with the > > > > registered interpreter. > > > > > > > > This is useful when wanting to launch a collection of binaries > > > > under the same interpreter, even when they do not necessarily > > > > share a common extension or magic bits, or when their magic > > > > conflics with the operation of binfmt_elf. Some examples of its > > > > use would be to launch some executables of various different > > > > architectures in a directory, or for running some native > > > > binaries > > > > under a sandbox (like firejail) automatically during their > > > > launch. > > > > > > Could you expand on the use cases? > > Likewise, I would also like to hear about the intended use cases. > > > A non-security use case would be to run the binary (without > > modification) with a different ELF interpreter (assuming this > > allows > > to override binfmt_elf, but self-sandboxing would need that as > > well). > > This would make it easier to use older or newer libcs for select > > binaries on the system. Right now, one has to write wrappers for > > that, and the explicit dynamic linker invocation is not completely > > transparent to the application. > > I think this is a slightly contrived use case. Normally you would > just use patchelf, or build the binary with a specific dynamic loader > e.g. -Wl,--dynamic-linker=file. What is restricting the use case from > modifying the binary or running under the new loader? Or to put it > another way, what requires the interpreter selection to be fully > dynamic? > > Why isn't the answer: Use ELF everywhere and specify the interpreter > you actually want? Likewise if you know you want to one-off run a > native binary in a sandbox or alternate loader then use a userspace > tool to do that? So I'm now worried about the stacking case: if you're emulating the architecture for the binary, which is the traditional binfmt_misc use case, you can't use this xattr trick to override the elf interpreter because the sequence goes binfmt_misc -> qemu-user -> elf_interp meaning qemu-user has to know to look in the xattr. Doing patchelf fixes this case as well, so it sounds like the better solution. James -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
