[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: [Plash] Re: Zero-install and Plash
Fwd: [Plash] Re: Zero-install and Plash
Sat, 29 Jul 2006 18:15:44 +0100 (BST)
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
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
- 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
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