Domining,
I really appreciate your thorough review. I left some comments below:
>> 1. Architecture
> You also need to add the case where an application is launched by pressing an icon
> or where an application is started by an other application (either as a service request or via a mime request).
> In the case of an App requesting an other app launch,
> AMD may not directly be able to read the the requester ID from the socket and you might be forced to add support for an other indirection.
Launching an application by pressing an icon of by other application is basically same in the view point of AMD. Either service request or MIME request is only used to identify the destination target and it is just peer-to-peer connection after the target is determined.
>> To support multi user, the hard-coded uid 5000 should be eliminated.
>> Current launchpad forks new process and sets the hard-coded uid 5000.
>> To solve this issue, I made the following changes:
>> - AMD receives the launch request from different users and identifies
>> the caller information by reading socket (SO_PEERCRED).
>> This information is passed to launchpad daemon by bundle with AUL_K_UID and AUL_K_GID.
> Getting the correct ID is a first step, you also need to set the same environment before lauching the App,
> in particular the $HOME $DISPLAY and D-Bus session. SO_PEERCRED provides the information needed
> to get the caller ENV via /proc/PID/environ
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?
>> Unlike the agenda, current patch has hard-coded uid/gid for fallback behavior. This hard-coded fallback IDs
>> are used only for the request from root user not to break currently working binary image. By current policy,
>> all the user apps should run under proper uid, not root. However, current implimentation breaks this policy
>> as several platform daemon launches user apps in root privilege and the fallback uid/gid prevents this issue.
>> This fallback uid/gid can be easily removed with proper platform policy.
> The falback policy does not sound like something that it would be desirable to kept in the code.
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.
>> 2. Behavior
> Any application accessing D-Bus session and the $HOME will require to get the call environment properly set.
> Is that something that you have already implemented in your prototyping code ?
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.
>> 3. Further Works
>> - App directory policy for TIZEN 3.0 should be fixed. With the app directory hierarchy policy, installer
>> or proper module should organize the filesystem layout and the launching process should make use of it.
> It's not only the App directory, the various system DB (e.g. App_Info, ...) as well as the APP DB needs rework.
> Some because they will need to shared between users (e.g. WRT.db) some because they are local to one user (e.g AlarmDB)
Right, current platform db or vconf should be located on the proper location.
>> - Handling the information from AMD to launchpad daemon using bundle key is fragile. The security guy raised the
>> issue and launchpad should only accept the request from AMD by using caller pid verification.
>> However, this is not included yet but it can be easily implemented without issue.
> Alternative could be to merge AMD and Launchpad. Differences between Wrt-Lauchpad (HTML5 Apps) and
> Launchpad (OSP Apps) are light and merging these deamon would snot only solve the risk associated to
> the data handling between AMD and Launchpad, it would avoid a bit of code duplication.
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.
Young
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
