[Dev] Cynara

Patrick Ohly patrick.ohly at intel.com
Wed Apr 9 12:35:25 GMT 2014

On Wed, 2014-04-09 at 12:27 +0200, José Bollo wrote:
> On mer, 2014-04-09 at 09:30 +0200, Patrick Ohly wrote:
> > Access control: I understand that a service will have to implement this
> > access control mechanism and I see how Cynara will help with this. What
> > hasn't become clear to me is how a service running as a normal user
> > process (same PID as all other apps of the user) will be able to protect
> > its data files from those other processes when using the 3-domain Smack
> > model. Can someone point me towards documentation for that, ideally with
> > an example? Will it be possible to write services that grant direct
> > read-only access to files (for performance reasons) while handling
> > writes in the service?
> I really agree with that remark. That is why I proposed a launcher that
> is aware of the problem of sharing/not sharing the filesystem.
> (see https://lists.tizen.org/pipermail/dev/2014-April/002292.html)
> I think that because smack rules modification will become lighter, the
> launch time will be less than 1 ms.

I've seen that. With that approach, apps can be restricted, but process
not getting that treatment would still have full access to everything. I
wonder whether we can do better than that.

Regarding the launcher, does it still grant the restricted app access to
the system and session D-Bus? Can it reduce access rights for files
and/or directories from "read/write" to just "read"? That would be
important for the "fast read-only access, secure and controlled write"
use case.

> > API + upstream: getting patches depending on Cynara into upstream
> > projects might be hard, depending on the project and how tolerant they
> > are of ifdefs. Would it be possible to provide a compat layer that acts
> > like Polkit but underneath calls Cynara? It doesn't have to be ABI
> > compatible to the GObject API, some limited API compatibility might be
> > good enough to get upstream code compiled on Tizen.
> That is a good idea. Can you estimate how hard it will be? I'm afraid
> that it could be complicated.

I've no idea. I'm just bringing it up as a wish-list item ;-}

> > Cynara API: you mention a single API function. Will that be synchronous
> > or asynchronous? If synchronous, how are services expected to remain
> > responsive will a policy check runs? Multithreading? My main concern is
> > a policy check which involves the authentication agent and thus user
> > interaction; normal policy checks probably will be fast (but still...).
> IMHO it should block and be "as if mono thread". It would simplify the
> development process of the library, leaving details of multi-threading
> to the integrator. It would be very painful to launch a thread to wait
> some answer or to provide a file descriptor for the glib loop, the qt
> loop, the ??? loop ....

Isn't glib the de-facto common standard? Qt on desktops is compiled with
glib integration support. I've seen that EFL also has code for it. I
don't know how either of these get compiled for Tizen, though.

Regarding "leaving details of multi-threading to the integrator": that
may simplify the work for the lib developer, but it complicates the
usage of the lib for service developers, in particular if those services
are not yet multithreaded. Just saying.

Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

More information about the Dev mailing list