On Thu, Jun 30, 2011 at 03:09:16PM +0200, Johannes Schauer wrote: > Hi, > > On Wed, Jun 29, 2011 at 10:46:57PM +0200, Yann Dirson wrote: > > * 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. > An idea of mine to solve all those issues is, if qemu-user-static would > interpret an environment variable containing the elf interpreter prefix > that is normally given with -L. > > I opened a wishlist bug for qemu here: > > If this is implemented in qemu, one would do something like this: > > export QEMU_LD_PREFIX=/tmp/debian-sid-armel/ > fakeroot fakechroot chroot /tmp/debian-sid-armel/ dpkg --configure -a > > and by that one would no longer need /etc/qemu-binfmt/, would also > always have the fitting shared libraries for each built, would need no > root access to the build host and so on - probably targets all the > issues you have correctly listed above. > > what do you think?
That's more or less the same idea, and as I said the security issues must be well thought out: > 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. That is, the binfmt declarations for qemu-static have "flags: OC", which means it will honor setuid binaries... -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
