[Dev] Multi User activation idea.

Hanchett, Paul phanchet at jaguarlandrover.com
Thu Oct 3 05:15:34 GMT 2013


Your link seems to be broken...  :-(


Paul Hanchett
-------------------
Infotainment Engineer
MSX on behalf of Jaguar Land Rover
One World Trade Center, 121 Southwest Salmon Street, 11th Floor, Portland,
Oregon, 97204

Email: phanchet at jaguarlandrover.com
-------------------

Business Details:
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]
> 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
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131002/1d5876f3/attachment-0001.html>


More information about the Dev mailing list