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
Reply to: