[Dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue

Saxena, Sunil sunil.saxena at intel.com
Tue Oct 8 04:30:59 GMT 2013


Please use dev at lists.tizen.org<mailto:dev at lists.tizen.org> for Multiuser discussion.  Removed deprecated mailing list tizen3dev from this mail.

Thanks
Sunil
From: 조영익 [mailto:youngik.cho at samsung.com]
Sent: Monday, October 07, 2013 9:20 PM
To: Saxena, Sunil; Lynch, Rusty; 김영걸
Cc: tizen3dev at lists.tizendev.org; 배선욱; 김정훈; 김명; 조승모
Subject: [Tizen3dev] Tizen 3.0 proposal for fixing OSP/WRT/Core hard-coded UID issue


Hello,



By the last action item from Tizen3 Architecture F2F, I report the status of removing hard-coded uid 5000 by the action item.



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.



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.

- 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.

- 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.



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.

- 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.



Thanks,

Young





[cid:image001.gif at 01CEC3A4.834E9060]

[http://ext.samsung.net/mailcheck/SeenTimeChecker?do=5b5b806e569672b02b51393f9d2e28ce35b7353596f11044d45acf71830d6fb152df871bea66fa4cb1bc0ee137ab2fc8c7b41e955949e5c8a728c55b39cc59eacf878f9a26ce15a0]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131008/37f0621e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 14036 bytes
Desc: image001.gif
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131008/37f0621e/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aul_multiuser.diff
Type: application/octet-stream
Size: 6100 bytes
Desc: aul_multiuser.diff
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131008/37f0621e/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libprivilege-control_multiuser.diff
Type: application/octet-stream
Size: 2942 bytes
Desc: libprivilege-control_multiuser.diff
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131008/37f0621e/attachment-0003.obj>


More information about the Dev mailing list