[Dev] Multi User activation idea.
phanchet at jaguarlandrover.com
Thu Oct 3 05:15:34 GMT 2013
Your link seems to be broken... :-(
MSX on behalf of Jaguar Land Rover
One World Trade Center, 121 Southwest Salmon Street, 11th Floor, Portland,
Email: phanchet at jaguarlandrover.com
Jaguar Land Rover Limited
Registered Office: Abbey Road, Whitley, Coventry CV3 4LF
Registered in England No: 1672070
On Wed, Oct 2, 2013 at 1:07 PM, Schaufler, Casey
<casey.schaufler at intel.com>wrote:
> > -----Original Message-----
> > From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org]
> > 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
> > cases are still very open what will require to support rather more than
> > 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
> > 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
> > 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
> > - 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
> > 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
> > 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
> > (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
> > 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.
> > for binary compatibility would be an extended target to which it's a bit
> > 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
> > would be in charge of providing services to the all active users.
> How (and why) would this be different from a regular, well implemented
> > 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
> > 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
> Dev mailing list
> Dev at lists.tizen.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev