[Dev] Multi User activation idea.

Schaufler, Casey casey.schaufler at intel.com
Wed Oct 2 20:07:00 GMT 2013


> -----Original Message-----
> From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On
> Behalf Of Dominig ar Foll (Intel OTC)
> Sent: Tuesday, October 01, 2013 10:42 AM
> To: dev at lists.tizen.org
> Subject: [Dev] Multi User activation idea.
> 
> Hello,
> 
> 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 services.
> 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.

Using Linux UIDs to identify people by account is a Tizen 3 security requirement. UIDs are kernel level identifiers and are fundamental to the discretionary access controls that have been widely and successfully used since the 1970's. Citing middleware that was written strictly for a single user system as a shortcoming of the Linux UID scheme is a fallacious argument. The user management functions you've called out have many existing implementations on multi-user systems. You have said very little about the "Linux current model" and much about the specific implementation of several user space facilities.

> 
> 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 :
> https://docs.google.com/spreadsheet/ccc?key=0Als7BiE7yLZQdFlaWmZwW
> HVRSmFqdkE5ZHhLXzMyUEE&usp=sharing
> 
> It certainly not complete but gives a quick idea of the spreading of the
> various issues.

It is true that there is a lot of work to be done on the Tizen middleware in order to support multiple users.


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

It is clear that lots of work is required to solve the problem.


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

Using separate UIDs to identify different users is a Tizen 3 security requirement. That is more important than reducing the work required to get a system working. The way the Tizen runtime hardcodes the "app" user is not a viable approach, and needs to be repaired.

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

OSP needs work for a number of other reasons. Avoiding fixing OSP cannot be a driving factor.

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

How (and why) would this be different from a regular, well implemented service?

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

This model is a bandage on top of an infection. It does not correct the problems, it attempts to put a wrapper around the issues. 

> Enjoy your day.
> 
> --
> Dominig ar Foll
> Senior Software Architect
> Open Source Technology Centre
> Intel SSG
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev


More information about the Dev mailing list