[Dev] Multi User activation idea.
Dominig ar Foll (Intel OTC)
dominig.arfoll at fridu.net
Tue Oct 1 17:41:34 GMT 2013
I am looking at how to enable Multi User support in Tizen 3 in order to
support new use cases such as :
- Dual SIM for Phone
- Multi Drivers/Passenger for IVI
- Multi familly members profile for TV
The interesting technical challenge comes from the fact that most of the
use cases are still very open what will require to support rather more
than less features while we have a serious legacy of code (Platform and
more important Apps) that we like to protect without reducing our
security and performance objectives.
Not to add, it must be simple to implement quickly with a small team :-)
1) Linux current model
While Linux core is very capable to support multi user usages in
traditional desktop environment, the requirement for connected devices
such as phones or IVI are not that well covered by the basic Linux
For example, there is no base services to propagate a Language or Time
Zone to several users or to enable applications,at the installation
time, for a few user only or to disable some applications for the driver
when the car is moving.
Futhermore many middleware assume an exclusive use of critical resources
(e.g. HW video decoder) to the benefit of the current user.
In short, Linux does a lot but not what we need out of the box.
2) Current situation with Tizen 2.x
With my team, we did a feasibility study on the activation of Tizen base
middleware (including the Web Run Time) and we noticed that some of the
architecture options which had been taken for Tizen 2.x where quite
problematic when it come to multi user activation.
Our Key finding are the following :
- run as root but serve a user context
- run as root but is controlled from a user context.
- use hard coded UID/GUI
- use hard coded Login name
- provide a user service but use setuid
- direct unprotected access to the configuration DB
- use hard coded unique fixed path for user specific data storage
* Configuration Databases
- no separation system/user/apps config user (only one big common zone)
- non access conflict Management
We maintain a table with our last finding that you can see at this link :
It certainly not complete but gives a quick idea of the spreading of the
3) Our initial path
During the summer we investigated a first model using a traditional PC
approach based on Tizen 2.1 where user data are stored in home
sub-directory. While the model allowed to provide some level of
multi-user support it did required :
- modifying a lot of source code (even if we limited our investigation
to enabling the WRT)
- forced us to break Tizen security model
- did not provide the level of facility required to support nor Mobile
nor IVI complex use cases.
- would require to touch code of most of OSP App.
4) Our new line of thought
This is my main motive of this long email. We would like to get your
feedback on our new proposition.
As our finding shows that most of the modifications are relative to the
use of :
- fix UID (app:5000)
- setuid in user related daemons
- fix data path for private data
- direct access to configuration DB
We should be able to launch each user session in a dedicated mini
container (User Name Space and Mount Name Space only) in such a way that
the existing user related daemon run as "local" root to allow them to
spawn the applications with a "local" user app (UID 5000). Access to
private data is done with a "local" fixed unique path compatible with
Tizen 2.x Apps which is mapped in Multi User friendly tree.
Access to the configuration DB still requires some investigation work.
If as we believe, it is confirmed that Apps never do direct access to
the configuration DB but always use a daemon services (quite a few :-(,
the modifications required will be contained.
While we did not investigate in detailed OSP Apps, there is no reason
why this solution would not provide a full source backward
compatibility. Asking for binary compatibility would be an extended
target to which it's a bit early to commit.
5) Resources creeping and security
In order to better secure the system while sharing as much as loaded
code between the active users to reduce RAM usage, we are investigating
the possibility to run some common services in a dedicated mini
container which would be in charge of providing services to the all
This model would allow to run some service at system level (without
being root) what could be very valuable for some profile (e.g. unique
sound manager on a dual SIM phone, single PVR engine on a TV with
children and parent profile, ...) as well as sharing heavy subsystem
I will share with you our findings soon.
6) Tell us your thoughts
Feedback on the proposed model as well as a description of your multi
user use cases will be well appreciated.
Enjoy your day.
Dominig ar Foll
Senior Software Architect
Open Source Technology Centre
More information about the Dev