[Dev] The SAPI proposal

Patrick Ohly patrick.ohly at intel.com
Tue May 27 16:01:38 GMT 2014

On Tue, 2014-05-27 at 17:41 +0200, José Bollo wrote:
> Hi Patrick, please accept my excuse for being so late in my answer.
> On ven, 2014-05-23 at 16:15 +0200, Patrick Ohly wrote:
> > On Fri, 2014-05-23 at 14:33 +0200, José Bollo wrote:
> > > Hi all,
> > > 
> > > I just finished the wiki page that describes SAPI, the Secure CAPI,
> > > proposal: https://wiki.tizen.org/wiki/Security/SAPI
> > > 
> > > SAPI, the secure CAPI, is an implementation of the CAPI over IPC. The
> > > clients call the service SAPI through an API implementing CAPI. The
> > > service SAPI checks the privileges using Cynara.
> > 
> > When it does that, what would it pass as session_id string to
> > cynara_check()?
> Good question. The problem of the definition of the session id is as
> open as the session id itself. Seriously, I expect that SAPI knows what
> session ID semantic to use. Not sure if possible 100% of the time.

I am asking because for a while it looked like only services could come
up with good session ids; this might not be true after all. Some of the
proposals (hash of "pid + process creation time") are easy to compute by
any component in the system.

Either way, I want to verify that this aspect is covered by the SAPI
proposal. It would be embarrassing to commit to a concept and then find
during the implementation work that the concept is broken.

> The advantage of SAPI is that not the client and not the service have to
> change (in an idealistic world ;)

This is a different from the argument in the Wiki because it now
includes not having to change services.

So the argument is that both clients and services are hard to change
(maintainers not committed to do the work; large, inconsistent code
base), and thus the work for enforcing security has to be done elsewhere
more efficiently. I can agree with this point of view; in fact, this is
why I (and others) have suggested that dbus-daemon should do the
enforcement for D-Bus services.

> > You mention one more advantage on the Wiki page:
> >  * Unification (simplification) of the API across the applications;
> > 
> > The proposal does not include changing any of the APIs used by
> > applications. Care to clarify what exactly it unifies or simplifies in
> > applications?
> What I meant is that the use of DBUS can be through glib or directly and
> the developers often write wrappers around this calls. Having a more
> high level API would simplify and will make clients more resembling.

But that's not part of the SAPI proposal, at least not as it stands
today, is it?

The page lists only existing CAPI packages. It says nothing about
creating new CAPIs. Is that also proposed?

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