Hi, Here I drew another diagram based on current design for better discussion. https://docs.google.com/drawings/d/1F3MKXqb_3KFOrEGqv65UhYRhf_3knWo7-6g5XpyM0iU/edit?usp=sharing
As I mentioned in my last mail, one constraint on current AMD is that: They get the client PID through socket attribute and retrieve the corresponding app info by that PID(parse AppId from /proc/PID/cmdline). If we use one xwalk-launchpad for all apps of an user, then the AMD can’t find the right app info to handle its AUL request. I’m not that familiar with security part, but from my perspective we can still forbid malicious access in xwalk-daemon. Regards, Xiang From: Crosswalk-dev [mailto:crosswalk-dev-boun...@lists.crosswalk-project.org] On Behalf Of Baptiste Durand Sent: Wednesday, February 19, 2014 1:46 AM To: Poussa, Sakari Cc: Le Foll, Dominique; crosswalk-dev@lists.crosswalk-project.org Subject: Re: [Crosswalk-dev] Intent to implement: [Tizen] Application API Hi all, I've started a discussion with stéphane Desneux (responsible for multi user aspects on Tizen) See the diagram that presents our proposal. https://docs.google.com/drawings/d/1egayWqb2lC0LWdRLYeVqO_IFe-beQA94bykZCdO67Zc/edit?usp=sharing We introduce another process called xwalk-launchpad that would replace your xwalk-launcher process for TIZEN. This process should manage all Applications dedicated to 1 user ( LifeCycle + Events) : -> it will be responsible for privileges check at launch time. -> it will handle and/or propagate events to AMD. Having a process for 1 user session is for us the best compromise between your initial proposition, the footprint on HW resources and the robustness of the application FRWK. the xwalk-launchpad is the right place to handle RUA per user (Recently Used Application). Our proposition seems also better for security aspects related to IPC used for Application Frmk, we prefer to use secure sockets instead of dbus session communication for isolation and security reasons: -> privileged daemon (root) must not communicate through user session dbus. -> credential features on secure socket are more secure than dbus policies (a user process won't be able to hack / fake anything.) We had a look in the source code ; especially application_service for browser communication side and we would like to propose a Tizen specific provider that manages the socket communication with xwalk-launchpad. This could be implemented through a new class xwalk/application/brower/application_system_tizen.[cc/h]. This one could be compiled for tizen OS only (OS_LINUX && OS_TIZEN), by this way we keep the existing working code. Thanks in advance for feedbacks. BR, Baptiste DURAND / Stéphane DESNEUX 2014-02-17 19:46 GMT+01:00 Poussa, Sakari <sakari.pou...@intel.com<mailto:sakari.pou...@intel.com>>: Hi, My short assessment of this is that 1. We need to integrate xwalk to talkd with AMD 2. AMD needs a socket interface which we should implement on xwalk-launcher BR; Sakari From: <Ming>, Bai <bai.m...@intel.com<mailto:bai.m...@intel.com><mailto:bai.m...@intel.com<mailto:bai.m...@intel.com>>> Date: Monday, February 17, 2014 at 3:14 To: Baptiste Durand <baptiste.dur...@open.eurogiciel.org<mailto:baptiste.dur...@open.eurogiciel.org><mailto:baptiste.dur...@open.eurogiciel.org<mailto:baptiste.dur...@open.eurogiciel.org>>> Cc: "crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org><mailto:crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org>>" <crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org><mailto:crosswalk-dev@lists.crosswalk-project.org<mailto:crosswalk-dev@lists.crosswalk-project.org>>> Subject: Re: [Crosswalk-dev] Intent to implement: [Tizen] Application API On 02/15/2014 01:14 AM, Baptiste Durand wrote: Hello, thanks for your answers. I would like to point a fact. In the current implementation (avaible on tizen.org<http://tizen.org><http://tizen.org>), xwalk deamon is launched by xwalk.service start script. This is stored to /usr/share/dbus/service/ . That means there will have 1 xwalk-deamon per user session started. As I understand, The aim of Xwalk Launcher is to manage the process group ( Render process & Extension Process ) nedded for an application ... Xwalk Launcher manages the Application Life Cycle of the associated application not only the launch action, correct? The name of this process migth be changed . it seems to be a confusing name. Indeed. For a multi user ascpect, AMD should manage all UserS applications for all user. In the documentation, there is not detail about the IPC that AMD should use to communicate with all "Xwalk-laucher". Could you provides more details on it? An xwalk deamon can launch applications only for 1 display (the display environment can not be changed it is static environement) Indeed,A xwalk deamon associated to a dbus session . So associated to 1 User - 1 Display.... On IVI, user & Diplay should be dissociated .... Please take a look on : in mutli user part (start at p 9) https://wiki.tizen.org/w/images/9/9d/TizenArch-MultiUserV20140202.pdf How do you manage seat changement with this architecture? In other words, users can exchange their displays. Regarding the display issue, currently we haven't considered too much. Perhaps it worth another detailed discussion. Thanks in advance for your answer.... -- Baptiste DURAND Eurogiciel Vannes/FR -- Baptiste DURAND Eurogiciel Vannes/FR
_______________________________________________ Crosswalk-dev mailing list Crosswalk-dev@lists.crosswalk-project.org https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
