Re: [Plash] Plash Wiki

[Mark Seaborn]

David Hopwood <address@hidden> wrote:

> Mark Seaborn wrote:
> > In particular, right now I am working on a package
> > system for installing Debian packages into Plash sandboxes.  There is
> > more information on the wiki:
> > http://plash.beasts.org/wiki/PackageSystem
> 
> # Plash's package tools will install packages into a sandbox from outside
> # the sandbox.
> 
> Is it not preferable to install packages into one sandbox from another
> sandbox? Or did you mean to include that possibility?

Yes, I meant to include that possibility.  That should be "install
packages into a sandbox from outside *that* sandbox".

There are two problems here though.

The first is setting up the application's private filesystem.  We can
do that by copying files, but that will waste a lot of disc space and,
perhaps more importantly, memory, when duplicate library files are
loaded.  It will also be slow.  We really want to share file inodes
between sandboxes when file contents are the same.

My current implementation does that by unpacking packages into a cache
directory and then hardlinking the files into the destination
directory (see Story1).  The sandboxed program shouldn't be granted
this directory directly; the directory must be wrapped in a
FsObjReadOnly proxy or a FsObjCopyOnWrite wrapper.

Hardlinking between directories is currently not implemented for
sandboxed code; hardlinking is only implemented for the
within-directory case (see FsObjReal).  That's not a big problem
because the implementation can be fixed.  However, it's not possible
to hard link a FsObjReadOnly file object into a FsObjReal directory.
So you can't use that as a way to create a persistent directory tree
of FsObjReadOnly files.

To address that I'm considering introducing a new, immutable directory
object whose contents are stored in a file as a list of hashes --
similar to Git's representation of directories but without any gzip
compression. (Story4)

That would provide a way for programs to build and share immutable and
persistent trees of files without having to be trusted with the
ability to write to those files.

The second problem is another persistence problem.  In order to
install an application we have to give the user a way to run it.  For
GUI apps on GNOME/KDE, that means creating a .desktop file containing
a command to run.  That must obviously be done by a trusted component.
If a sandboxed program is going to set up an application to run, we
need a way to reproduce the authority it had, i.e. some persistence
mechanism, so that it can create a capability and hand it to the
trusted component to create a .desktop file that will invoke that
capability.  Which is doable, but trusting the installer is simpler
for a first version.

Mark

Wiki pages mentioned above:
Story1:  http://plash.beasts.org/wiki/Story1
Story4:  http://plash.beasts.org/wiki/Story4
FsObjReal:  http://plash.beasts.org/wiki/FsObjReal
FsObjReadOnly:  http://plash.beasts.org/wiki/FsObjReadOnly
FsObjCopyOnWrite:  http://plash.beasts.org/wiki/FsObjCopyOnWrite