On 2014-05-15 11:59, Kis, Zoltan wrote: > On Thu, May 15, 2014 at 11:55 AM, Zhang, Xu U <[email protected]> wrote: >> [Zhang Xu ] Patrick, Bai (who has left Intel) and I have designed crosswalk >> API permission control. The doc is here >> https://docs.google.com/a/intel.com/document/d/137u_gxmNaIFwVzaCkCFBJyveIdZxuAydWOkMI8oWgD0/edit > I think that's a good/flexible design. App process invokes an API > function. The renderer process (RP) sends a message to the extension > process (EP), which checks whether permission is granted. On need the > browser process (BP) pops up a user dialog. > >> and the implementation is done. I am informed that all web device APIs >> implementation should use Cynara’s service API directly. So the design will >> be dropped from web runtime side. >> I will implement crosswalk runtime security issues. > Here we have options. > > A. Security (service) proxy is the only enforcement point. Dominig's proposal. > In this case the EP is totally transparent and inherits the app identity. > We need to solve how the browser process will know to pop up a user > dialog for permissions. > Also, all API's that are accessed by the web runtime need to be > exposed by the service proxy, which is a huge work with huge delay. > > B. There may be multiple enforcement points (EP, dbus-daemon, > service-proxy). This allows direct DBUS access from apps, and in the > rest works like in A. Sub-options: > 1.) EP is also enforcement point, and part of the system. Then, EP > checks if access is allowed, either by > a) asking Cynara, or > b) EP caches policy data from Cynara (with an update/sync mechanism > for that data) and makes a local decision, which is much faster than > a).
Minor note: B1b would not be faster than B1a, it would only add overhead. Cynara will provide a library (libcynara-client) for access checks and it will already implement caching. On cache hit in libcynara-client it won't contact the Cynara daemon, but just return cached value. Cache flushing should also be transparent for Cynara users.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
