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