[gobolinux-users] Unionfs to replace sandbox?

Jonatan Liljedahl lijon at kymatica.com
Thu Oct 13 14:22:02 GMT 2005

On Thu, 13 Oct 2005 04:03:01 -0400
Nick Matteo <kundor at kundor.org> wrote:

> On Thursday 13 October 2005 03:43, Jonas Karlsson wrote:
> > As I say further down, using the unionFS in the sandbox should only
> > be last resort. I can see uses for unionFS instead of links though
> > (have no idea of what impact that would have on speed).
> Jonatan did some testing with the unionfs replacing links; performance
> was quite bad, unfortunately.  That's why I thought it would work well
> as a replacement for just /S/K/M, where listing/finding performance
> isn't particularly important, and it fixes the issue of 'removing
> provided modules when a package is removed.'
> > To me this looks like a "treat the symptoms but not the
> > disease"-approach. I think that the unionFS only should be used when
> > there is no other way to make the installation play nicelly. How
> > would the installation environment look like? Will it have the
> > legacy file system, just to please the program we are installing?
> Actually, it can treat a lot of problems the Gobo approach has.  For
> instance, if we install parts of KDE in their own directories, they
> all look under /Programs/KDE-Foo/Version for the rest of KDE and don't
> find it.  To get around this we need to maintain a huge list of
> $KDEDIRS.  If they all look in /System/Links instead, everything works
> and we can put different parts wherever!
> Same goes for everything where a program expects to find other files
> where it is installed:  extra modules, plugins, shared data, etc.  If
> we tell it that it is installed in /System/Links, then it will find
> all those things provided by other packages.  So we can't let it know
> that it is actually in /Programs/Foo/Ver.  The only way to do that is
> to allow it to _think_ it's been installed to /System/Links but really
> put it somewhere else.
> What this means is that unionfs cannot just be a fallback approach for
> sandboxing. To get this to work, it has to be used to install
> everything; even 'well-behaved' programs need to be tricked into
> thinking they are really in the Links hierarchy.
> See http://www.gnu.org/software/stow/manual.html#SEC7

I think it's a very good idea to move over to UnionFS for sandboxing.
There's a lot of good things coming out of it, and I don't see it as a
problem that more apps could be installed without beeing patched. IMHO,
the goal with the Gobo tree is to have a clean and easily maintained
system, where each component lives in a separate dir. We can NOT make
all unix programs adapt this tree and install directly into it, they all
need to be tricked. Some apps is easily tricked, some are not. But the
goal is to trick them and make them install into the Gobo tree while
still finding themself and other stuff... UnionFS will help here, a lot!

/Jonatan    -=( http://kymatica.com )=-

More information about the gobolinux-users mailing list