Re: [Plash] Permissions in .pkg Files

[Toby Murray]

On Mon, 05 May 2008 12:51:00 +0100 (BST), Mark Seaborn wrote:
> Toby Murray <address@hidden> wrote:
> 
> > It would appear to be useful to be able to grant coarse-grained static
> > permissions such as
> > - Access to network (pola-run's --net option)
> > - Access to X11 (pola-run's --x11 option)
> > - Access to Record Audio (read access to /dev/dsp or similar)
> > - Access to Play Audio (write access to /dev/dsp or similar)
> 
> Yes, there needs to be a way to grant these rights.
> 
> The long term aim is to have a GUI for installing an application and
> granting it rights.

Indeed. Long-term, I imagine that you might have an installer that
generates .pkg files (or something akin to them). These files then serve
not only as a description of how to install the package (or more
precisely, how  the package was installed) but might also serve to store
persistent permissions granted to the application by the user via the
powerbox.

> I have been regarding the .pkg file format as a temporary solution.
> It does double duty: it stores what the application requests or
> suggests (such as the application's name), and it also stores what the
> user chooses.  The user chooses the application's pet name by editing
> the file, but this could be done via a GUI.
> 
> We could do something similar with these coarse-grained access rights,
> and have a few boolean fields in the .pkg file to record whether the
> sound device, the network, etc., should be granted.

This would be my preferred short-term option.

If the .pkg files are a temporary measure, designed to be replaced by
something more extensible and (possibly) interoperable in the future,
then using them as a short-term means to experiment with strategies for
granting persistent permissions (such as these static permissions and
those granted by the powerbox) might be acceptable.

> How or whether an application should be able to request these rights
> is another matter.

I agree and believe that it should be kept so as well. (i.e. this issue
should be kept out of the current discussion.)


> It wouldn't be hard to add these fields, but it doesn't seem very
> extensible.

I agree but given the temporary nature of the .pkg file scheme, I'd
argue that (ab)using them in this way would be a good experiment -- if
nothing else to learn how to go about it the right way.

> One factor is that we will often want files/directories that have been
> granted via the powerbox to be persistent.  Files granted to a music
> player need to be persistent, for example.  The simplest
> implementation for persisting file grants would store a list of
> pathnames of files to grant.  This would be structurally the same as a
> list of -f and -t options to pola-run.  However, that does not provide
> a way to support granting unusual objects such as union directories
> and copy-on-write directories.  This would probably require a
> generalised system for persistent object references.

Another way to get around this would be to abandon the .pkg file
solution in favour of python objects that subclass a general object and
provide the necessary information by overriding the object's fields.
That would allow the use of the python APIs directly within the config
file and, thus, allow one to build up complex environments directly.

One would expect that these .pkg files (or whatever they evolve into) to
be machine generated in the long term -- by some installer. Hence,
having a format that isn't necessarily designed to be foremost human
readable may not be such a problem.


> > Also, how does Plash interact with D-BUS, which seems to have become a
> > mandatory service that all GNOME apps require access to these days?
> 
> Plash doesn't know about D-Bus yet.  I guess we might have to tame
> access to D-Bus objects.  Do you have any D-Bus objects or services in
> mind?

No. I'm just aware that more and more applications require it these days
and have no idea about how it (internally) manages permissions to access
and implement (e.g. masquerade) as various services. This is interesting
because certain security-oriented services have gained traction recently
(e.g. PolicyKit).


> If an application wants access to a D-Bus bus without requiring any
> particular objects from it, it is easy to launch it through
> dbus-launch to give it a private bus.
> 
> Cheers,
> Mark
> 
> 
>