Date: Wed, 23 Dec 2015 12:43:52 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: musl & proprietary programs On Thu, Dec 24, 2015 at 12:22:05AM +0700, Рысь wrote: > On Wed, 23 Dec 2015 15:48:53 +0100 > Szabolcs Nagy <nsz@...t70.net> wrote: > > > * Alba Pompeo <albapompeo@...il.com> [2015-12-22 13:37:52 -0200]: > > > chroot is a little better than dual-boot, but still very unfriendly > > > for a day-to-day usage of many proprietary tools. > > > > > > > on x86, binaries linked against glibc can be made to work with > > musl. > > > > but isolating such software into a separate virtual environment > > is a good idea anyway and then it's easier to use glibc based > > userspace there. > > Well that's fine until you will not face something dynamic. A simple > example: some of my machines successfully runs LibreOffice 4 inside > Slackware 14 chroot. Problems start when user wants to save a document > to USB stick. This is a valid use case, but fails because you end up > with mounting USB stick twice. This requires wrappers. And in *DE > environments they will be lost under pressure of various mount daemons > or something like that. But at rest, it works flawlessly. > > Maybe Alba Pompeo just faces an issue with wide filesystem tree that > needs to be inside chroot. I don't see why chroot is necessary at all. If you want a glibc environment for a single app you can put all the glibc stuff in its own library path and either invoke the binary manually using the glibc dynamic linker or have (a symlink to) the glibc dynamic linker in /lib. Then it can access the normal filesystem just fine. Containers (or just chroot) are of course preferable when you actually do want to isolate the program for trust/privilege purposes, but they're not a technical requirement for running foreign-libc binaries. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.