On Wed, May 14, 2014 at 3:50 PM, Lukasz Wojciechowski <[email protected]> wrote: > > W dniu 2014-05-14 07:43, Zhang, Xu U pisze: > >> >>> -----Original Message----- >>> From: Dev [mailto:[email protected]] On Behalf Of Patrick Ohly >>> Sent: Tuesday, May 13, 2014 10:29 PM >>> To: José Bollo >>> Cc: [email protected] >>> Subject: Re: [Dev] enforcing priviliges of web apps >>> >>> On Tue, 2014-05-13 at 16:09 +0200, José Bollo wrote: >>>> >>>> On mar, 2014-05-13 at 15:59 +0200, Rafał Krypa wrote: >>>>> >>>>> On 2014-05-13 14:29, Patrick Ohly wrote: >>>>>> >>>>>> On Tue, 2014-05-13 at 11:13 +0000, Counihan, Tom wrote: >>>>>>> >>>>>>> I will end up with a total count of 1 browser process and 4 >>>>>>> other processes (2x extension & renderer) = 5 processes? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is this correct? >>>>>> >>>>>> And to extend the question, which process will be the one talking >>>>>> to the rest of the system services? >>> >>> [...] >>> >>>> I agree with you. There is a problem. Is was thinking that the W3C API >>>> was handled at the renderer process level. Having it common to all >>>> apps is a problem for the reasons you written. >>> >>> Note that my question about "which process talks to services" (or, in a >>> similar >>> vain, accesses files) has not been answered yet. It might still be the >>> per-app >>> render process which does it. >> >> [Zhang Xu ] Tizen extension APIs will be implemented in extension process. >> So extension process in crosswalk will talk to service. >> For W3C APIs, it is up to how system implements W3C API module. For W3C >> APIs other than Tizen extension APIs in crosswalk, the process which >> implements the module follows the design of chromium. In chromium, the >> render process will send IPC message to browser process firstly. And browser >> process will talk to the service to get the result. Then browser process >> will transfer the result to render process.
That is for internal extensions. Tizen API's (and W3C API implementations in Tizen) are external extensions to crosswalk. > > If we follow such design all calls to services will be made by browser > process and not by application process. It means that services won't be able > to provide application granularity access control because all calls will be > made with SMACK label of browser. > It is a problem. Except if the browser / extension process become security enforcement points, doing the runtime checks. Since they are different processes than the the one running the app, they could load a library implementing the runtime security checks and enforce permission. Of course then the platform becomes as secure as the browser... but Chromium security is rather high. Best regards, Zoltan _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
