[Dev] Tizen 3.0 Multiuser support architecture proposition

김정훈 david_kim31 at samsung.com
Sat Oct 26 05:34:57 GMT 2013


Hi Dominig,

I attached the material instead of Young.

Regards,
David.


------- Original Message -------
Sender : YOUNG IK CHO<youngik.cho at samsung.com> S5/Senior Engineer/Service Platform Group/Samsung Electronics
Date : 2013-10-25 20:52 (GMT+09:00)
Title : Re: Multi user details questions.
 
Sorry for late response. Mr. Bae, would you post the previous material instead of me please?
 
Actually there is a minor issue for $HOME directory. On the *NIX world, the actual user directory is /home/{username}. However, I proposed /opt/usr/uid instead of /opt/usr/username. There is subtle issue of assigning username in the literal form and I think using uid instead of username is fine. The file standard hierarchy does not specify the user directory name in detail and we just need to maintain symbolic link of /home correctly.
 
I will leave the comment and internal discussion soon.
Regards,
Young
 
 
------- Original Message -------
Sender : Dominig ar Foll (Intel OTC)<dominig.arfoll at fridu.net>
Date : 2013-10-24 17:16 (GMT+09:00)
Title : Multi user details questions.
 
Young,

1) as said I will push a joined presentation on the mailing list Monday 
evening (CET). It would have been nice if your slides could have been 
pushed as a response to my posting of last week.
It would show that the discussion is open.
can you do that ?

2) File position.

Your proposition (slide 5) derive from mine (slide 9), on the private 
file position.
In your slide 5, you have some private files in $HOME and some other in 
/opt/usr/uid.

Only the $HOME can be retrieve in a reliable manner from via pam. So I 
propose to move the all the user private file in /opt/usr/uid in $HOME

Both files system are in rw. If for any reason on your vertical you need 
to get those file on a different fiile system than $HOME, you can use a 
mount -bind.

As soon as your slide deck will be in the public mailing list I will 
post that comment in public.

If you have a good reason to propose that for the common base 'all 
verticals), thanks to explain it to me.

Regards


-- 
Dominig ar Foll
Senior Software Architectese
Open Source Technology Centre
Intel SSG

From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On Behalf Of Young Ik Cho
Sent: Sunday, October 20, 2013 12:27 PM
To: Dominig ar Foll (Intel OTC)
Cc: dev at lists.tizen.org
Subject: Re: [Dev] Tizen 3.0 Multiuser support architecture proposition


Here follows my comments:
  - p5 : AMD should be single entry point for "App".
          Direct request to launchpad with associated bundle information
This is as Tizen 2 is implemented today. As you can see in my proposal for Tizen 3 I propose to have only one entry point.
 
Actually launching without AMD works on TIZEN 2.x as AMD/aul supports extra functionality. app_efl_main(), the entry point for all the Tizen app, internally invokes aul_get_appid_bypid() function and aul looks for /proc filesystem if it cannot find the app list from AMD. This fallback behavior incurrs slight performance penalty around 50msec on target but is maintained to support shell execution and WebApp behavior.
 
 
  - p9 : Can I get more information on the statement, "Apps are added in
user session from outside"?
Launchpad is running with privilege (e.g as root), so when it launch the App is does create a context (environment variables and uid/gid) which is the "same" as if the App was launched in the user session.
This is needed to get the right HOME, DISPLAY, Locale, D-Bus session, ...
I got it. However, apps are always add in user session from outside as we do not allow fork()/execve() officially and all launch request is forwarded to AMD.
 
  - p11: I totally agree that some DB should be cached or some module
should provide better method for performance.
          The most of DB access on app launch is package DB. In my
opinion, most of the package DB information should be reside in the
shared memory to reduce expensive DB access if it does not have security
issue. WRT-related DB also should provide similar mechanism.
          For Tizen DB, there is already a guideline from security, Mr.
Lim, that only daemon can write DB and client is only read it on TIZEN 2.2.
Would you have a pointer to give me?
Tizen CORE (or OSP) module already follows a guideline similar to your suggestion: no client can write DB directly.
 
 

  - p16 : I am not sure that TLM(TIzen login manager) should be included
TIZEN common platform or not.
Devices which needs multi user login will need something. Do you have an alternative proposition ?
No, I just say that I am not sure it's the role of application framework. It's role of the profile or commercial vendor to use login manager or not.
 
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Multi_User_uid_draft.pdf
Type: application/pdf
Size: 329801 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131026/27062193/attachment-0001.pdf>


More information about the Dev mailing list