On Tue, May 13, 2014 at 1:38 PM, Baptiste Durand < [email protected]> wrote:
> For each user we have only 1 Browser process > And per User applications there are 2 process > 1 render process (RP) > 1 Extension Process (EP) > > So > The browser process is in charge of W3C API > The extension process is in charge of tizen API > All W3C API for All Application for 1 user are managed by the Browser > Process . > > Yes, this is correct. The browser runs the JS code implementing the API shim, which communicates via JSON with the extension processes (at least for external extensions such as Tizen extensions, since the internal extensions use the Chromium internal IPC). The extension processes are the ones implementing the platform specific code, which maps the JS shim to the platform code (e.g. to DBUS, or platform library interfaces) needed for API implementations. The extensions may have multiple instances running (different pages = different instances). Now since Chromium uses libevent based mainloop, the extensions need to launch a thread to run the glib mainloop in order to be able to talk with DBUS. There may be one of these per extension/instance. This thread has to have the permission to access DBUS. >From here we have two options: - either the extension 'inherits' the identity of the app, and eventually fails in accessing DBUS, since the app doesn't have permission and the system denies access - or the extension can always access DBUS, and acts as a security manager: check app id/manifest/web permissions, map it to platform permissions, and enforce security policy. In this model, native apps could also access the platform DBUS interfaces, and security needs to be enforced e.g. in the DBUS daemon (by assumed Cynara extensions to the dbus daemon). An alternative model is what Dominig proposed. If I got it right, both native apps and the Crosswalk extension processes would access the platform only by using a library or libraries which expose the platform API in question and implement an IPC (e.g. low latency zeromq) to the service proxy process, where the following are done: - app (native or web) identification - mapping of web permissions to platform permissions - enforcing the platform permissions according to the platform/device security policy - mapping the API calls to the platform API's: DBUS or other. The main drawback here is the need to map every single platform functionality to a new API, and then which API? The C API? OSP/C++? ASD IDL->C++? An intermediate 'mother of all' API to which all previous are mapped? Looks very idealistic/irrealistic to me, given the limited time and resources we have. Also, the optimal process model of the service proxy is not clear. My question is, would the first model work, i.e. - xwalk extensions are part of the system and enforce web API permissions (or alternatively are transparent, but can still access DBUS) - DBUS interfaces (e.g. BlueZ, ofono, connman, etc) are secured by extensions to the DBUS daemon, so that native apps could use DBUS if they have declared the mapped permissions and the policy allows it - other cases could go through the service proxy or proxies. Best regards, Zoltan
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
