On Thu, May 15, 2014 at 1:27 PM, Rafał Krypa <[email protected]> wrote: > 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.
Very nice, thanks! That leaves either A, B1(a), or B2 as options, the main issue being to patch dbus-daemon for supporting Cynara and hence allowing direct access from native apps and crosswalk extensions. What is your take on this? Thanks, Zoltan _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
