[Dev] Multi user support propositin

Dominig Ar Foll dominig.arfoll at fridu.net
Thu Oct 10 20:42:58 GMT 2013


Hello,

following a few email exchanges on the topic relative to multi user
support for Tizen 3.x, I would like to submit a new proposition for
feedback.

1) Tizen 2.x legacy
============
Tizen 2.x was built for single user mode without any consideration for
multi user support.
We inherit codes with many Multi User offender legacies that will need
addressing. We can classify them as follow.

 - hardwired UID/GUI/Login
 - hardcoded path
 - direct access to Tizen data base
 - no provision for creating or removing users

The result of code scans that was done to write this proposition can
be seen here :
https://docs.google.com/spreadsheet/ccc?key=0Als7BiE7yLZQdDJqOVFyWGlFU1ZMckZ3MTZWS2R3Z3c&usp=sharing

Thanks to Baptiste, Stéphane and Xavier for the help in that task.

2) Hardwired UID/GUI/Login
=================
a) Current situation
---------------------------
Several hardwired UID/GID/Login were used in Tizen, the most
prevailing one being the user app (UID:5000).

Quick code scanning shows that the use of hardwired ID is very well
spread in all the code and affect almost 100 different files which
will need patching.

b) Proposition
-------------------
as users will be created dynamically either by a default Linux utility
or by a dedicated daemon (that later option will likely be preferable
but is not critical at this stage of reflection), this implies that
their UID will be dynamic.
- Each software needing to know it's own ID will have to use the
corresponding system call [e.g. getuid()] to extract it.

- each daemon needing to launch an application for a given user will
not be in position to assume the the UID 5000 any more for the app
user. The UID of the caller will need to be extracted from the calling
method.
 I propose to extract the caller UID with getsockopt, check the
connection validity and then read the execution environment from the
systemd-user existing for that user.
The main advantage of that model, is that it a small deviation from
the exisiting Tizen 2.x model and keep the key Application FrameWork
(AppFW) daemons unique what limits the access conflicts to the various
Tizen databases (DB) (see specific issues relative to DB below).

3) Hardcoded Paths
===============

a) Current situation
--------------------------
Hardcoded path have been commonly used to access DB, share directories
and private directories.
Quick code scanning shows that the use of hardwired path is very well
spread in all the code and affect almost 100 different files which
will need patching (see spreadsheet for details).

b) Proposition
-------------------
Create a dedicated package which will use as data source a unique
include .h file which will describe all the generic paths in absolute
for the common path and relative to $HOME for the user paths. The
package will provide the following :
 - creation with correct access right of all common path
 - initialisation of all common DB
 - -devel package to ease inclusion of a .h file in c/c++ code
 - creation of a config file which mirror the content of the .h to be
sourced by scripting language (e.g. /etc/sysconfig/tizendir)
 - utilities to add and remove a user from common DB entries and
create/delete private user DB and paths.

4) Direct Access to DB
=================

a) Current situation
--------------------------
Code scan, shows that access to the DB is done directly though sqlite
calls by about 50 programs. We need to differentiate 3 cases :
 - access to common DB done by one (or a few) privileged daemons
 - access to private DB done by user apps
 - access to common DB done by user apps.

Note: When debugging the WRT under Tizen 2.1, it was noticed that more
than 200 access to DB where required to launch a single application.
This is due to the coding model used to access to the information
contained in the DB. While this is not directly linked to Multi User
operation, it will need to be fixed at the same time, because it
creates unneeded long lock on DB.

b) Proposition
-------------------

I propose to limit access to the common DB to a limited set of daemon.
It seems that it will be already the case as soon as all the DB
relative to a single user will have been moved to the right place (see
spreadsheet link at the beginning of this mail).
My proposition is to restrict access to 1 daemon as writer limit to a
few as readers.

For user DB (e.g. mail, last run apps, ...) I propose to move them in
the $HOME in a dedicated directory (see hard path correction
proposal).

For mixed directory (e.g. MediaDB which covers private and shared
area), we propose to create a set of private DB for user specific
content and a common DB for shared areas. MediaDB (common and private)
would be accessed via a dedicated daemon. That model would avoid to
run indexing several time on shared area (note shared areas will
include non local domains accessed remote access such as DLNA).


5) Provisioning/Removal of users
=========================

a) Current situation
--------------------------
Tizen 2.x does not provide any mechanisms to support user add/delete.
Some init script exist to scan installed app and associated populate
DB but more or less we have a blank sheet.

b) proposal
---------------
Creation of a dedicated service which will not only create/delete the
user at linux level (/etc/passwd, ...) but will also create the
(empty) private DB and register the user in the common DB.
This service should be UI-less and accessed by request such as D-Bus
or Unix Socket to remain generic to all verticals.

6) Not covered
=========
Privilege management (libprivilege-control) and system configuration
(vconf) are under review by other teams, so I have to wait for their
input to comment on the proposed new model.


-- 
Dominig ar Foll
Senior Software Architect
Intel Open Source Technology Centre


More information about the Dev mailing list