<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2014-05-15 11:59, Kis, Zoltan wrote:<br>
<pre wrap="">On Thu, May 15, 2014 at 11:55 AM, Zhang, Xu U <a class="moz-txt-link-rfc2396E" href="mailto:firstname.lastname@example.org"><email@example.com></a> wrote:
<pre wrap="">[Zhang Xu ] Patrick, Bai (who has left Intel) and I have designed crosswalk API permission control. The doc is here <a class="moz-txt-link-freetext" href="https://docs.google.com/a/intel.com/document/d/137u_gxmNaIFwVzaCkCFBJyveIdZxuAydWOkMI8oWgD0/edit">https://docs.google.com/a/intel.com/document/d/137u_gxmNaIFwVzaCkCFBJyveIdZxuAydWOkMI8oWgD0/edit</a>
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.
<pre wrap="">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
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
<div style="bottom: auto; left: 112px; right: auto; top: 89px;
display: none;" class="translator-theme-default"