← Back to team overview

elementary-dev-community team mailing list archive

Re: elementary's path forward for application containment and security.


Contractor only implements the first one it does not fetch data for an app,
it just enables the application to send its data to another application for
further work.

The latter would require more work on the 3rd party application while the
current setup just needs a contract file and everything else works.
On Mar 19, 2014 9:59 AM, "Cameron Norman" <camerontnorman@xxxxxxxxx> wrote:

> I guess what I do not understand is how the application gets the data by
> executing the command. What I see in that implementation is simply a return
> of a command to run with an existing file as an argument, instead of a way
> to retrieve a new file.
> The difference is that the former says "I have a <type>, what can I do
> with it?" while the latter says "I want to do something with a <type>,
> how/where can I get one?".
> El Tue, 18 de Mar 2014 a las 8:45 PM, Akshay Shekher <
> voldyman666@xxxxxxxxx> escribió:
> The earlier implementation IIRC worked in the following way.
> App -> contractor [give me a list if programs that handle file type x]
> <- [program a b ... ..]
> App asks the user to select one or selects one itself and
> App -> Contractor [program Id x, for file/uri y]
> <-  [command string]
> App executes this using execv or something similar.
> The '->' is for dbus function calls and '<-' for return.
> Dbus is just a protocol for doing interprocess communication so a
> program/script can use contractor if it can use dbus.