My understanding of the current model is very different from what I see in this discussion.
One AMD, running with appropriate privilege. At user session initialization AMD is sent a notification that includes the relevant information about the user session. At user session termination AMD is sent a message about the termination. To launch an application a message is sent to AMD by the user. AMD looks at the SO_PEERCRED information to reliably determine the UID. This is used to identify the user session. Since AMD already has the relevant information about the user session no further action is required. If the home directory and other information for the user environment is desired it must be given to AMD at session initialization. From: [email protected] [mailto:[email protected]] On Behalf Of Dominig ar Foll (Intel OTC) Sent: Monday, October 14, 2013 7:16 AM To: [email protected] Subject: Re: [Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue Young, please find extra comment in line in the text. Dominig ar Foll Senior Software Architect Open Source Technology Centre Intel SSG Le 14/10/2013 14:34, YOUNG IK CHO a écrit : I did not consider the environment variable seriously so far. Currently, $HOME and $DISPLAY is inherited from launchpad process but it should be set properly on the multi-user environment. Launchpad invokes _set_env() function to set its internal environment variable but it sets only PKG_NAME so far. However, some module should provide additional information like $HOME or $DISPLAY to to be set. Myabe the directory policy should be deternined also: where is $HOME directory for each user? In a single user model, lauchpad, has the ENV information because all the system was hard-wired. In a multi user model, we have ENV variable that will differ from user to user and might not even be fixed. Prime candidates are Display and D-BUS related variable. All the challenge is to fine a simple but reliable method to obtain the ENV if the user session and pass them over to the lauchpad via amd. This is to keep compatibility with current behavior. However, Either or both of the following should be done to solve this issue: - Some platform daemon should run in the user-session. - Some system-session daemon should use an explicit API to specify the user id. Challenge is to pass the access token (what ever they are) from the deamon runing in the user-session to the launch daemon. No, for my prototyping, all user process shares $HOME=/root environment variable. Currently most of systemd-related API uses system session instead of user session and simple launch test does not detect DBUS-related use case. Nice to see that we still get some serious issues to play with. Do you have an idea to pass that ENV. We had quite active chat on the mailing list on the issue but convergence is slow. Thanks to shot your vision of a solution in the discussion. Right, current platform db or vconf should be located on the proper location. It's not only location. We also need to deal with access conflicts and the obvious over use of DB access during launching. Well, the code itself does not seems to be that different but the wrt-launchpad has additional platform initialization and process-pool utilization. To avoid the code duplication, it is desirable to make shared library to be shared for lanchpads. That might be a nice compromise between full redesign and code duplication. Dominig
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
