Re: [PATCH] polystrap-binfmt for preparing the build host
On Thu, Jun 30, 2011 at 08:02:04AM +0200, Johannes Schauer wrote:
> > > 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?
Multiarch will still require root permissions for package
installation, and will not solve the qemu-arm issue.
> Do you have a proof of concept for your idea inside a fakechroot?
Not yet - I've had a long AFK period shortly after this discussion,
and I'm still handling backlogs :)
> 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
>
>
> --
> To UNSUBSCRIBE, email to debian-embedded-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: http://lists.debian.org/20110630060204.GA5498@hoothoot
Reply to: