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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
