Re: [PATCH 2/3] fs/binfmts: Better handling of binfmt loops

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Quoting Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>:

On Tue, 30 Jul 2013 16:16:51 -0700 Zach Levis <zml@xxxxxxxxxxxxxxxxxx> wrote:


Quoting Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>:

> On Thu, 25 Jul 2013 08:40:44 -0700 Zach Levis <zml@xxxxxxxxxxxxxxxxxx> wrote:
>
>> With these changes, when a binfmt loop is encountered,
>> the ELOOP will propogate back to the 0 depth. At this point the
>> argv and argc values will be reset to what they were originally and an
>> attempt is made to continue with the following binfmt handlers.
>
> hm, why?  What problem does this fix?  What value does the change offer
> to our users?

This is used when the binfmt_misc,script,etc options are configured in
a way that would previously prevent executables from launching that
could be executed with a different binfmt but don't because of a loop
in a prior binfmt.

Example: a qemu is configured to run 64-bit ELFs on an otherwise
32-bit system. The system's owner switches to running with 64-bit
executables, but forgets to disable the binfmt_misc option that
redirects 64bit ELFs to qemu. Since the qemu executable is a 64-bit
ELF now, binfmt_misc keeps on matching it with the qemu rule,
preventing the execution of any 64-bit binary.

So the admin can unforget to make that change and no longer has a problem.

With this patch, an error is printed and search_binary_handler()
continues on to the next handler, allowing the original executable to
run normally so the user can (hopefully) fix their misconfiguration
more easily.

Is all this really worth changing the kernel for?  It sounds
a bit marginal.
I'd say it is worth changing because this is a self-contained fix that doesn't have much in the way of side effects for normal execution but can help recover a system. Apart from storing a pointer to the provided arguments, the only changes this requires are in the code for error handling.


--
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




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux