[Dev] Multi User activation idea.

Counihan, Tom tom.counihan at intel.com
Wed Oct 2 09:44:44 GMT 2013



> -----Original Message-----
> From: dev-bounces at lists.tizen.org [mailto:dev-bounces at lists.tizen.org] On
> Behalf Of Lukasz Stelmach
> Sent: Wednesday, October 02, 2013 10:25 AM
> To: Dominig ar Foll (Intel OTC)
> Cc: dev at lists.tizen.org
> Subject: Re: [Dev] Multi User activation idea.
> 
> It was <2013-10-01 wto 19:41>, when Dominig ar Foll (Intel OTC) wrote:
> > 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
> 
> Set LANG and TZ environment variables.

Do these not have a system wide impact, resulting is all users picking up the same values?
If so, consider from an IVI perspective we have a 'user' which is the system administrator - i.e. the guy in the garage that pulls logs, and diagnoses problems.
If the owner/driver sets the language to something that administrator cannot understand could this not be perceived as an issue? If the OEM wishes to ensure that all logs/diagnosis traces are captured in one language, could the use of these env variables override such a policy?

What happens if we have multiple concurrent users - drivers/passengers that what different language experiences?

> 
> > or to enable applications,at the installation time, for a few user
> > only
> 
> I've talked to ... a Ubuntu Touch guy some time ago. They've decided to install
> apps in home directories. IMHO device adminitrator should be able to choose if
> an app is to be available to all users or not. Everyone else can install apps only
> for personal use. Users should be able to share apps
> 
> > or to disable some applications for the driver when the car is moving.
> 
> This is rather a matter of a shell (window/desktop manager) running on the
> driver's seat.
> 
> > Futhermore many middleware assume an exclusive use of critical
> > resources (e.g. HW video decoder) to the benefit of the current user.
> 
> Unfortunately, sometimes hardware design makes it next to impossible to
> share it. Actually codecs (at least those my teammates worked with) are able to
> decode up to 16 streams if the streams are not too wide. And they say it is
> available in kernel.
> 
> 
> > 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
> 
> This is BAD.
> 
> >    - run as root but is controlled from a user context.
> 
> I do not quite understand why this should be bad. Such deamons should
> implement some policy to decide which requests they should serve and which
> to deny.
> 
> >  * 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
> 
> BAAAD.
> 
> > We maintain a table with our last finding that you can see at this link :
> >
> https://docs.google.com/spreadsheet/ccc?key=0Als7BiE7yLZQdFlaWmZwWHVR
> S
> > mFqdkE5ZHhLXzMyUEE&usp=sharing
> >
> > 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
> 
> Few days ago a new security model has been discussed on one of (dev ||
> tizen3dev) our lists.
> 
> >  - 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
> 
> There is a small issue we have faced some time ago. If we want (do we?
> it would be nice) the root file to be read-only then we need a user database a
> bit more advanced than /etc/{passwd,groups}. We need the traditional Linux
> files (they may be read-only) to store the system accounts (bin, daemon,
> messagebus etc) and another to store human users (this DB needs to be
> writable).
> 
> > 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.
> 
> UID namespaces are considered problematic, to say the least. The problems
> begin when you create files in a UID namespace. Then, the security team (I've
> just asked them to write a little bit more about it
> here) has their own idea of how to use containers.
> 
> [...]
> 
> > 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.
> 
> I am afraid you trust containers too much and forget about real security
> measures (SMACK in our case). Containers are not meant to provide security.
> 
> http://www.youtube.com/watch?v=Sz-
> S7fqgjvA&feature=player_detailpage#t=485
> 
> I hope, I wrote something useful.
> 
> --
> Łukasz Stelmach
> Samsung R&D Institute Poland
> Samsung Electronics
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.



More information about the Dev mailing list