> -----Original Message----- > From: Dev [mailto:[email protected]] On Behalf Of Dominig ar Foll > Sent: Monday, June 16, 2014 1:06 AM > To: [email protected] > Subject: Re: [Dev] The SAPI proposal > > Hello, > > I would like to remmeber yopu that the concept of SAPI has been > introduced in order to enable the provision of a Native API support as > required by some profiles without having to create two independent > security frameworks.
Native application support is hypothetical. I suggest that before we sink time and money into a solution to the native framework problem we define the native framework. That way we can determine if our solution solves the problem we have. I am averse to implementing SAPI without a clear understanding that it will be necessary and sufficient to address the problem. > In Tizen 2.x the security was directly managed by the WRT and Native > application had no security model. > > In Tizen 3 we know that some profiles will require the support of Native > and Hybrid Applications. If we follow the same path than in 2.x we will > need to implement a security model in Crosswalk (the new WRT) and create > an other one for Native Apps. > > Not only this double the double the work, it also increase security risk > as it is unlikely than the two frameworks will behave the same. > > Adding a unified security framework in Tizen is a model which would push > to the level of Android. > > I understand that it is far away from traditional Linux desktop, but > that is not what we are targeting with Tizen. > > Regards > > Dominig > > > Le 13/06/2014 15:37, José Bollo a écrit : > > Hi Zoltan, > > > > On ven, 2014-06-13 at 13:25 +0300, Kis, Zoltan wrote: > >> On Thu, Jun 12, 2014 at 5:50 PM, José Bollo > > (SNIP) > >>> - To manage the critical resource/service acquiring or sharing > >>> between users and applications. > >>> This is very important for the multiuser case inside the framework. > >> Could you list specific examples? For audio [/video/network/cpu] > >> policy we already have Murphy. > > The profile IVI is using murphy. The profile mobile is also using a > > specialized component to arbitrate resources. SAPI doesn't aim to > > replace any of them but instead aims to cooperate with them when > needed > > if needed. > > > > It is hard to give an example. The only one that is coming to me is > > related to an other kind of problems: switching the resource from an > > application to an other when the former is going to be paused in the > > background while the other is activated in front. > > > >>> - It is convenient to use a good C API (as opposite to use UDS or DBUS). > >>> Thus some C API will be needed to not access low level API. > >> How do you handle asynchronous idioms, e.g. [DBUS] signals/listeners, > >> the existence/appearance of [DBUS] interfaces/objects with the C API, > >> etc? > > Core API uses DBUS in some parts but the question of handling > > asynchronous signals/listener isn't fully solved currently. What I can > > say is that Core API doesn't expose dbus interface. It defines all the > > types and callback itself using the good old c. It will be easy to add a > > verb to dispatch events. Core API is maybe using a kind of ecore loop in > > some cases, what is an other difficulty, but I still have to check (Help > > welcome). > > > >> Depending on external factors (provider, location etc), services may > >> present different sets of interfaces. > >> If you implement a general purpose mechanism for this, you get close to > libdbus. > > That is what we dont want to do: making a general purpose libdbus. And > > it is why using Core API is good: because it is hiding details while > > bringing what is needed to implement the well defined TIZEN APIs (web > > and native). > > > > (SNIP) > > > >>> For critical timing resources, the API would be mainly used > >>> for signalisation and the data would be streamed by . For the direct > >>> accesses, data would go aside: using a file descriptor received from > >>> UDS, using a service (like gstreamer), or filesystem (with > >>> namespaces or not). > >> This signaling will be done for each system API call? Then you need to > >> wrap every system API call in the SAPI, and performance hits will be > >> huge. > > What is system API? If libc then the answer is no, it is out of the > > scope of SAPI that concentrate on Core API. > > > >> Or is there a notion of a "session" when an app gets a session-token > >> for accessing the resources permitted by the manifest at a specific > >> point (installation, launch)? > > I'm sure that there is a notion of session. Cynara defines a such > > notion. I dont know if murphy also defines it. I'm thinking that a > > session is more dynamic, it is "on need". > > > >>> Noboby wants to check any frame of a video stream with Cynara. > >>> The camera API is designed to use gstreamer (such use case is an > >>> interesting security topic!). In the multi user environment of IVI, > >>> we are expecting to have more than one camera and to apply user > >>> policy when acquiring it. > >> Where are these 'user policies' checked, and could you list some use > >> cases? It seems overlapping with media/device resource policy what > >> Murphy is doing. IMO sapi-daemon should stick with handling the > >> security policies. > > Agreed. See above. > > > > (SNIP) > >>> The page https://wiki.tizen.org/wiki/Talk:Security/Overview is made for > >>> the discussion on this subject. > >>> > >>> SAPI is built on top of a FAST communication system. Many more fast > >>> than DBUS. > >> Do you mean zeromq or similar? > > Yes. Ideally, the transport part is changeable. But there is at least > > one feature needed: passing file descriptors. > > > >> Let me enumerate: for a web app, we have the following IPC hops: > >> - between the renderer and extension process (JSON) > >> - between the extension process (libsapi) and the sapi-daemon > (zeromq?) > >> - roundtrip between libcynara and cynara daemon (can be optimized out > >> by caching security policy data in libcynara memory) > >> - the rest of IPC for accessing the service (usually DBUS), perhaps > >> peppered with other roundtrips for service-specific resource > >> allocations. > >> > >> For native apps skip the first, but you have all the rest. > > Agreed. > > > >> So I think it is worth supporting and maintaining model 3 from > >> https://wiki.tizen.org/wiki/Talk:Security/Overview (patch libdbus + > >> dbus-daemon), since every app and existing extension will benefit from > >> it (no need to rewrite them, and much less extra latency). > > It also have drawbacks 8( Thank you for having check that talk page. > > Dont hesitate to add your comment on it, it is intended for. > > > >>> About BT, some work is currently done for making a BT framework (on > >>> DBUS) that will call BLUEZ (on DBUS). Thus SAPI could integrate directly > >>> the BT framework. So architectural design does matter in the discussion. > >> Yes, doing this per vertical makes sense. Telephony will likely be > >> done the same way. > > (SNIP) > > > > Best regards > > José > > > > _______________________________________________ > > Dev mailing list > > [email protected] > > https://lists.tizen.org/listinfo/dev > > -- > Dominig ar Foll > Senior Software Architect > Intel Open Source Technology Centre > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
