[Dev] User ID allocation

Piotr Bartosiewicz p.bartosiewi at partner.samsung.com
Fri May 23 08:16:31 GMT 2014

On 22.05.2014 20:39, Thiago Macieira wrote:
> Em qui 22 maio 2014, às 18:58:40, Piotr Bartosiewicz escreveu:
>> Who wrote that daemon is connecting to a session bus? It's not true!
> That's what I understood from the OP. Michal wrote about D-Bus socket. Since
> the system bus has no UID restriction on connection, I concluded it was the
> session bus. And since a UID is even being discussed, I concluded it was
> something with a different UID (system service) trying to connect to the
> session bus.
System bus has default rules as below:

<allow user="*"/>
<deny own="*"/>

Since we want to provide our interface on this bus, we should have
the 'allow own' rule saved in the container under

<policy user="our_user_we_are_talking_about">
     <allow own="com.samsung.containers"/>

>> In our solution we have three complete tizen systems: host system,
>> first container named private and second container named business.
>> There is a daemon on the host system which manages containers and
>> additionally has an ability co communicate with them by connecting to
>> theirs dbus system sockets (to clarify: there is no connection to session
>> sockets, there is no connection to host system socket, there are only
>> two independent connections between host daemon and containers
>> system dbus).
> There's no problem in that from the D-Bus side. You're talking about system
> buses, therefore any connection is allowed.
As above, theoretically connection is allowed, but registering object is 
> The bus restrictions are a different story.
The problem is that dbus protocol is not user-namespace friendly.
User namespace gives you an ability to map user IDs between container
and host i.e. idX in the container is visible as idY in the host and 
vice versa.
So if you create a connection from host from user ID=Y to the dbus inside
container, then dbus daemon see:
"I got a connection, kernel tels me that this is a connection from user 
but in protocol I see it is user ID=Y - its impossible, I will deny that!"
The easiest workaround for this problem is to ensure that this 
particular user
has a 1-to-1 ID mapping (other workaround would be to hack the dbus library
on the host).

>>> In any case, I still don't understand the problem. You're talking about a
>>> pair of UIDs and flashing the device...
>> The problem is that we need some user IDs to be the same in the host
>> tizen as in the container tizen (you can think of them as an independent
>> systems).
> I understand you need that. I don't understand what the problem is.
> You should use useradd -r in the host tizen system to create a system UID for
> you. Once you have done that, use useradd again in the container tizen but
> pass the UID, GID, shell path, home dir settings from the host system.
Suppose (for the purpose of this discussion) you've downloaded a containers
image from the www. In your solution the installation process should:
* add a user in host
* hack the containers image:
* - add this user with given ID (how to ensure it is not used already?)
* - chown relevant files or install this files after user was added

And the second example where we want the ID to be statically reserved:
We want the root (userID=0) inside container to be mapped to the user ID=Z
in the host. We can't afford to chown almost every file in the 
containers tizen
system to the newly created user on the host - it takes too long. If we 
know the userID while creating the containers image then no action would be
needed while installing this container.

Piotr Bartosiewicz
Samsung R&D Institute Poland
Samsung Electronics

More information about the Dev mailing list