[Dev] Multi User activation idea.

Łukasz Stelmach l.stelmach at samsung.com
Wed Oct 2 09:24:59 GMT 2013

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.

> 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


> We maintain a table with our last finding that you can see at this link :
> https://docs.google.com/spreadsheet/ccc?key=0Als7BiE7yLZQdFlaWmZwWHVRSmFqdkE5ZHhLXzMyUEE&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


I hope, I wrote something useful.

Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.tizen.org/pipermail/dev/attachments/20131002/fb99f1d3/attachment.sig>

More information about the Dev mailing list