[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 :
  * Daemons
    - run as root but serve a user context
    - run as root but is controlled from a user context.
  * Packages
   - 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 
various issues.

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 
active users.
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 
(e.g. Wayland).
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
Intel SSG

More information about the Dev mailing list