[prev in list] [next in list] [prev in thread] [next in thread] 

List:       klik-devel
Subject:    Re: [klik-devel] IMPORTANT: fakechroot issues summary of
From:       "Fabian Franz" <FabianFranz () gmx ! de>
Date:       2008-03-04 2:10:11
Message-ID: 20080304021011.301930 () gmx ! net
[Download RAW message or body]

Hello,

wow you found the only evening, where I have some time :-).

Great!

> Ok Linoel is away at the moment but I thought I'd summarise where we are
> at.

Okay.

> 
> We are currently using fakechroot to chroot our process to the mount
> point... this works but is not going to be a complete fix as far as I
> can tell.
> 
> The main issue is ld-linux.so.2 is the calling process so will NOT use
> the LD_PRELOAD library
> 
> The result is python modules will not load and certain calls escape
> (see opera issue
> http://code.google.com/p/klikclient/issues/detail?id=159)

Okay.

> Where do we go from here..... ?
> http://klik.atekon.de/wiki/index.php/Virtualization_Options
> 
> CLONE_NEWNS, can we merge this with our existing fusioniso? (I'm not
> really sure how this one works, will it have the same limitations
> without touching glibc ?)

Yes, it works by using real mounts, which are only available in one namespace.

It even uses pivot_root (a global chroot), so that is pretty safe.

A very detailed take on this is here:

http://mail.kde.org/pipermail/klik-devel/2007-February/000101.html

I did use uniofs or aufs as that I was aware of, but if your fuseiso can use real \
mounting via fuse that works as well.

Update: I just see that I even had already implemented a funionfs (fuse unionfs) so \
that should mek it very easy for that to do.

It might be even more secure as the fuse server is running outside of the chroot and \
not as root.

Note: I just saw: In the current version there is still a small "bug" as the fuse \
server is unnecessarily run as root ... (but that could be fixed easily)

So I could fix that, if you really were interested in going that road.

> PLASH / Plasticfs, requires a replacement glibc

Yes.

> Anybody have any opinions on this?

You could try the CLONE_NEWNS approach, though that needs another very small suid \
wrapper installed.

Perhaps it would be even possible to let the user choose the method ...

(kind of modular like klik already is)

Or perhaps even have those apps that are failing be prompting the user with the \
choice to install the suid wrapper or not to be able to run that.

I mean: fakechroot works well enough for most apps.

cu

Fabian
_______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel


[prev in list] [next in list] [prev in thread] [next in thread]