[Dev] Cynara

Patrick Ohly patrick.ohly at intel.com
Thu Apr 10 09:05:03 GMT 2014

On Wed, 2014-04-09 at 16:34 +0000, Schaufler, Casey wrote: 
> > On Wed, 2014-04-09 at 15:13 +0200, José Bollo wrote:
> > > On mer, 2014-04-09 at 14:35 +0200, Patrick Ohly wrote:
> > > You are right: apps not launched, not receiving the treatment have
> > > full accesses. But to my eyes it is not a problem because:
> > >  - Tizen enforces the use of launcher (for security) so what are the
> > > applications that aren't launched?
> > 
> > Which Tizen profile do you refer to here?
> >
> > In Tizen IVI there are several user processes which do not get spawned by
> > the launcher and thus have access to more data than they really need.
> Those are mostly services (weston, murphyd) and basic
> UI applications (weekeyboard). Everything on Tizen (true
> for Android, too BTW) has access to more data than it needs.
> The question is whether it has access to data that matters.
> Who cares if it can read /etc/tizen-release?

I guess it depends on the data and the goals. I'd certainly would be
more comfortable with a Tizen device where Weston, murphyd and
weekeyboard can't read or (worse) write my PIM data.

Whether it's worth investing extra effort is up to the people defining
the product and its requirements.

> > >  - DAC and MAC are still here filtering real intrusions
> > 
> > But that doesn't help when the uid and smack label are the same.
> > 
> > > > 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.
> > >
> > > Agreed too. But remember only if it doesn't want to block.
> > 
> > My expectation is that services will not be allowed to block. So either they
> > are multithreaded, asynchronous or both. Cynara as currently designed does
> > not fit into services which are asynchronous, but not multithreaded.
> Do we have services that are asynchronous, but not multithreaded?
> I'm all in favor of generality, but I don't believe in solving problems
> that we don't have.

As Jussi said, at least in the glib-based world, asynchronous without
multithreading is the preferred model. If you need a specific example:
syncevo-dbus-service, implementing the PIM Manager API in IVI, is not

There's one more related issue with having a single blocking API
function: suppose a service did create a thread to invoke that API and
then while the check still runs needs to shut down cleanly, or (perhaps
more realistic) the client asking for the restricted operation quits. A
service must be prepared for this, even if it is only in the error
handling paths. Can the service cancel the running call into Cynara?

If it can't then it can only kill the thread, without knowing in which
state that thread is.

Cynara also needs to be thread-safe itself internally, of course.

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