1. Architecture
There are two key daemons to spawn new process(app) in TIZEN;
AMD (application management daemon) and launchpad daemon. AMD
receives the launch request and forwards it to the launchpad
daemon (launchpad_preloading_preinitializing_daemon) and
launchpad is the parent process of all TIZEN apps. There are
three launchpad daemons; launchpad, wrt_launchpad and
debug_launchpad and AMD chooses the proper launchpad daemon
w.r.t. launch request. debug_launchpad itself is launched by
sdbd (sdb daemon) only for debugging purpose. Under TIZEN 2.2,
all these daemons run under the system session of uid root.
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.
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
- 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.
- libprivilege-control.so has more functions to handle
uid/gid. Legacy function exists not to leads build break.
- Wrt launchpad has similar changes like launchpad. Launching
WebApp involves process pool and each process pool should
handle uid setting also.
2. Behavior
aul package provides "launch_app" command to send the launch
request from the shell command prompt. By using "su" and
"launch_app" command, it is possible to change caller uid in
runtime. Following launching behavior is verified:
- CoreApp : Test core app is launched without issue
- OspApp : Launching OspApp from IDE leads to crash.
Installation itself is fine but IDE sends launch request using
"developer" (5100) account. However, osp installer sets "data"
directory for app (5000) user, not developer and it leads to
crash. After changing the "data" directory to world-accessable
(777 permission), it launches fine. This problem may happens
either for CoreApp or WebApp if it accesses "data" directory
and this should be resolved with global directory policy.
- WebApp : It works fine.
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 ?
Due to the fallback mechanism, org.tizen.indicator and
org.tizen.quickpanel runs on 5000 uid.
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)
- 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.
--
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
Intel SSG
|
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
