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. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
