Re: [PATCH] polystrap-binfmt for preparing the build host

On Wed, Jun 29, 2011 at 10:46:57PM +0200, Yann Dirson wrote:
> On Wed, Jun 29, 2011 at 10:27:06AM +0200, Johannes Schauer wrote:
> > Can you elaborate where you see the problem?
> 
> * working on arm and armel targets on the same host
> * targetting squeeze and wheezy on the same host
> * developpers with no root access to the build host
> * experimenting with changes to the -L tree used qemu, without
>   simultaneously breaking builds 
> 
> To put it short, /etc/qemu-binfmt/* solve a per-user problem in a
> system-wide manner.  This is bad in itself.
all agreed

> > I'm not sure whether you dont understand the problem that is to be
> > solved or whether I understand how you suggest something I dont see
> > a need to be fixed - please explain.
> > 
> > The $ARCH variable is being set in the config file and determines for
> > what debian architecture a multistrap is done. To figure out which
> > qemu-*-static binary to copy in the root directory, the above lines are
> > evaluated - how do you think that can be improved?
> 
> As seen above, there is no bijection between ARCH and BINFMT_ARCH, and
> several ARCH can map to a single /etc/qemu-binfmt/$BINFMT_ARCH/.
> 
> OTOH, when we're at the point of running qemu-*-static, we have
> already produced a rootfs that can be used by qemu to locate the libs,
> and which holds precisely those libs that would be used on the target
> system.  So why would we want to use another tree forced onto all
> users ?
> 
> Incidentally, I was given a suggestion to solve the problem, that
> should prove easier to implement that the ptrace-based approach, and
> whose description will hopefully make things more clear:
> 
> Instead of having qemu-*-static directly called by binfmt, we could
> call a wrapper script.  That wrapper would be able to pass the -L flag
> to qemu, depending on caller's choice, eg. through the use of an
> envvar.  If no envvar was set, then it could fall back to the
> system-default tree if any.
> 
> What annoys me in this approach, are the possible security
> implications of letting a user influence running binaries.  I suspect
> this could be applied to attack the system via setuid foreign
> binaries.  The user mechanism should at least be ignored in that case,
> much like LD_* envvars in the same case.
> 
> And that mechanism would be in conflict with the current
> qemu-user-static package, so coordination with the qemu maints will be
> required.
ah okay I understand now what you mean and I would also totally like a
solution to the /etc/qemu-binfmt/ problem. Using shared libraries from
the just extracted rootfs with the -L option would be an idea but
wouldnt it also be possible to let multiarch handle it?

Do you have a proof of concept for your idea inside a fakechroot?

That there is no bijection between ARCH and BINFMT_ARCH has also proven
to be a problem for me [1]. Now every time I build for armel or armhf I
have to change a symlink in /etc/qemu-binfmt which is very annoying.

josch

[1] http://lists.debian.org/debian-embedded/2011/06/msg00045.html