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>