Re: [atomic-devel] Container data and uid/gid

[Colin Walters <walters verbum org>]

On Wed, Jan 7, 2015, at 05:14 PM, Matt Micene wrote:

I may be overstating the case a bit, but ensuring uid/gid matches on shared volumes (regardless of Docker or otherwise) has always been a manual process. 

 

Right, generally.  The current Fedora recommendations are here:

 

https://fedoraproject.org/wiki/Packaging:UsersAndGroups

 

Which let's be honest, "fork the setup package and add an Epoch" is pretty terribly ugly.

 

So to reiterate briefly the reason manageable uid/gid allocation is important in Atomic is that:

 - Containers allow a lot of flexibility, except uid/gid is an anchor dragging it down

 - To implement atomic upgrades, rpm-ostree requires distinguishing locally added users from OS vendor users

 

I'm thinking even of the dark days with ORCL db usernames and shared storage volumes.  The only wrinkle here is we're talking about a UID/GID set that gets created by the RPM, not by an admin. 

 

It's both - and "the admin" is more interesting of a concept in a Docker world, which encourages pre-built images.

 

 

I've had issues with install order on systems creating UID/GID issues for shared or migrated content for as long as I've been an admin.

 

Right.

 

The OStree issue seems to be a merge issue, what happens if a locally created entity collides with a system created entity.  Install order should always be the same,

 

Install order will *definitely* not always be the same.  We've already hit issues with that in rpm-ostree as it's simply nondeterministic in general.  You can hope that if your input package set doesn't change, the transaction order won't, but that's about it.  Adding a package may cause a cascading ordering change, even if that package doesn't add a uid.