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
/etc/dbus-1/system.d/com.samsung.containers.conf:
<policy user="our_user_we_are_talking_about">
<allow own="com.samsung.containers"/>
....
</policy>
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
not.
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
ID=X,
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
would
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
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
