Fwd: [Plash] Re: Zero-install and Plash

[Mark Seaborn]

Subject: Re: Zero-install and Plash
From: "Thomas Leonard" <address@hidden>
To: "Mark Seaborn" <address@hidden>
Date: Mon, 17 Jul 2006 20:41:00 +0100

On 7/17/06, Mark Seaborn <address@hidden> wrote:
> "Thomas Leonard" <address@hidden> wrote:
> > On 7/16/06, Mark Seaborn <address@hidden> wrote:

[ sandboxing zero-install programs ]

> > plash$ !!0launch --download-only URI
> > plash$ 0launch --offline URI ARGUMENTS + ~/.cache/0install.net
> >
> > (read access to ~/.cache/0install.net could be added to the default 
> > environment)
>
> My thinking is that 0launch could download the files and then start
> the program using either pola-run or the Python Plash bindings.  It
> would build an environment consisting of the files in the zero-install
> package and its dependencies.  This way only the minimum required
> installation files would be present in the program's namespace.

It's a bit tricky. For example, ROX-Session depends on ROX-Defaults,
causing XDG_CONFIG_DIRS to include a directory in the cache with
sensible defaults. Other applications inherit this environment.

Also, the cache is read-only, public (and probably shared over p2p at
some point), and contains impossible-to-guess directory names
(preventing accidents), so there's very little to gain by restricting
access to it.

> In the ideal case I am assuming that there would be no need for a
> default environment, so it wouldn't grant access to /usr, /lib and so
> on by default.  Are there any zero-install packages that provide all
> their own environment, including libgtk, xlib, etc., through their
> dependencies?

No, but we may start listing them at some point. That would allow the
injector to select an older version of a program if a required native
library was missing, and to choose between a native library and a zero
install one (people keep complaining about having to download
libraries they already have).

[...]
> > Provide a '0launch-restricted' command whose interface is the 'safe'
> > subset of 0launch's (e.g., you MUST use '--download-only'). When
> > 0launch is run, it checks whether it needs to download anything. If
> > not, it runs the program. If it does, it runs 0launch-restricted (a
> > plash executable object) to get it in the cache first.
>
> I guess this works for a zero-install package that invokes another via
> 0launch (e.g. Gnumeric launching a Web browser to display help pages),
> whereas my proposal above doesn't.  Are there zero-install packages
> that invoke 0launch themselves?

Some of them. Build scripts (e.g. rox-release) are normally sandboxed,
and tend to run 0publish and gtk-2.4, for example. At some point, all
the build tools are likely to be run this way (gcc, scons, ...).

ROX-Filer and ROX-Session run various programs this way too, but
they're privileged anyway. Most programs run ROX-Filer (to view help
files or show the directory containing a file being edited), so a safe
subset of the ROX-Filer interface ("open a directory") is also needed.

> > How to you plan to support configuration settings?
[...]
> 2. The application is granted access to a freshly-created directory in
> which it can store configuration settings.  Having an instantiation
> step means you can create multiple instances of an app with different
> settings (and pet names) if you so desire.

OK, here's an idea. AddApp already creates a ROX application directory
for the launcher - how about storing the configuration settings in
there?

- Multiple configurations happen naturally.

- Deleting a 'launcher' deletes the configuration settings (no pile-up
of forgotten config files in hidden directories). Would require a bit
of user re-education.

> I'm imagining something like AddApp, but with a few configuration
> options.

So AddApp is really a way to add pets. Makes sense to me :-)

> Concretely, instantiating an app might work by creating a new file in
> a directory in ~/.config which would list:
>  - the zero-install URL of the application to launch
>  - public keys to trust when fetching program code/data
>  - pet name
>  - files/directories to grant the app access to when running it

Per-program keys is an interesting one. So far I've resisted, because
the extra confirmation dialogs might be counter-productive.

> > > I think the hard part is working out how to grant authority to the
> > > zero-installed program.
> >
> > > For a GUI editor we could generate a .desktop file (similar to how
> > > 0alias creates scripts) and associate it with file extensions such
> > > that when a file is double-clicked, the editor is launched with the
> > > right to access the file.
> >
> > I'd probably do that at the filer level (which is the graphical
> > equivalent the interactive plash shell). Seems strange to be only
> > sandboxing zero-install programs and not others.
>
> Yes, ideally all programs would be sandboxed, but many programs won't
> be able to work like that so we can't make that the default yet.
>
> Also, I think this ought to work in other file/program browsers, such
> as Nautilus, so that these can launch sandboxed zero-installed
> programs.  I think the only way to do this is to generate a .desktop
> file.  Or is there another level where we can hook in?

Not at the moment, but a 'run-program' command that is executed when
starting a program would be simple to hook into a variety of file
managers, I expect.

[...]


-- 
Dr Thomas Leonard               http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1