[Dev] The SAPI proposal

José Bollo jose.bollo at open.eurogiciel.org
Tue May 27 15:41:00 GMT 2014

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.

> > Some of us are thinking that it is a good proposal because:
> >  - Applications don't need to be rewritten (OSP ones)
> This is also true for the alternative (putting Cynara checks into the
> services themselves). I'm not saying that the alternative is better or
> worse; I'm just pointing out that this here isn't a difference between
> them and thus shouldn't be listed as advantage.

That would be true if all DBUS services are patched to be Cyanara aware.
The advantage of SAPI is that not the client and not the service have to
change (in an idealistic world ;)

> 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.

Best regards

More information about the Dev mailing list