[Dev] Multi user support propositin

Jussi Laako jussi.laako at linux.intel.com
Fri Oct 11 09:29:58 GMT 2013

On 10.10.2013 23:42, Dominig Ar Foll wrote:
> 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.

Our team has one implementation for this already, as a D-Bus service 
(supports also p2p dbus) and a client library. I am hoping to make the 
code publicly available soon to enable further discussion on the 
direction. Our implementation is not complete, but it has most of the 
functionality existing, so at least it can serve as a starting point.

User creation and population of home directories follow normal standard 
Linux ways with /etc/skel & co. In any case, it is planned to make this 
script-extensible. It is trying to be as stardard as possible, so you 
could also use with normal Linux desktop too. But otherwise we want to 
extend the user data capability with auxiliary database to store 
necessary extra information (TBD).

IOW, I think the specs Mikko referred to is quite good and should be 
used where possible. It is especially important to follow these to ease 
porting of Linux code and reduce number of bugs regarding upstream 
sources, because for example glib has functions to retrieve these XDG 
paths and those are used by a lot of open source software:

> 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.

I think (6) should be about session management. To handle GUI-less 
hardware-based login (primarily IVI) and also GUI-logins. Otherwise not 
that far from gdm/kdm/xdm.

We have a very draft skeleton for this plus plans for the necessary PAM 
integration and such (to enable NFC login using NFC stickers as a demo).

I'm hoping to make code for this too available in public soon.

Best regards,

	- Jussi

More information about the Dev mailing list