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-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/20110630060204.GA5498@hoothoot -- To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110820164815.gb30...@home.lan
