Post by Mark SeabornPost by Toby MurrayIt 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.
Post by Mark SeabornI 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.
Post by Mark SeabornHow 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.)
Post by Mark SeabornIt 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.
Post by Mark SeabornOne 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.
Post by Mark SeabornPost by Toby MurrayAlso, 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).
Post by Mark SeabornIf 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