It was <2014-05-23 pią 10:16>, when Piotr Bartosiewicz wrote: > On 22.05.2014 20:39, Thiago Macieira wrote: [...] >> 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.
I think I understand the problem, but this looks like UID per app (or whatever other entity) which wasn't meant to be supported in Tizen. However, I understand you need some way to solve it. Let me try. 1. Do you need to support the container users anywhere else outsied the container infrastructure. yes: this is going to be tricky no: no problem. 2 (I assume you've answered "no" above.) Create your own id allocation code that keeps track of id in a separate db and does not modify /etc/passwd at all. The only thing you need to take care of here is to make useradd not to use your ids. -- Łukasz Stelmach Samsung R&D Institute Poland Samsung Electronics
pgpGIFavXInGQ.pgp
Description: PGP signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
