We discussed this at today's meeting (​http://meetbot.fedoraproject.org/fedora-meeting-1/2014-12-11/fpc.2014-12-11-17.01.txt) and we need a lot more info about why dynamic uid/gid isn't enough anymore.

• 474 Allocating a soft static uid and gid 389 for dirsrv (geppetto,

  
  18:01:58)
• LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1143066
  (tibbs|w, 18:03:06)
• ACTION: james Need more data, we esp. don't want to set a precedent
  that anything that can be in a container needs a soft static
  uid/gid. (geppetto, 18:09:00)

...specifically what is being shared and why ... how many other applications do you think this will affect? Are there any plans to do anything longer term in upstream docker or elsewhere?

Dynamic uid/gid means that the image can be built once with with uid1/gid1 for the user under which the software runs and under which it accesses its data, and another time with uid2/gid2. As long as the software just stores the data in its image, it does not matter. But once you start using volumes, you want volume data produced by container run from image1 usable by container run from image2. For that you want the uid/gid of the running process (from image2) to match the uid/gid used for the data in the volume (generated by process from image1).

It's not really a sharing problem, it is an upgrade problem, primarily. With containers, the images are built independently, installing rpms from scratch, not via updates of rpms. So the uid/gid picked up by useradd can be different in every image you build because the yum transactions can serialize differently and the sequence of useradd's run by rpm scriptlets can be different across images.

It it my understanding that actually yes, anything which can produce data to volumes in a container will eventually hit the same issue and will need the static uid/gid. (If the software just runs in the container and maybe only produces some caches that do not go to volumes, it does not need it.)

I'm not sure about any other plans. In https://bugzilla.redhat.com/show_bug.cgi?id=1145981 I've proposed to make it much easier to use uidgid in scriptlets by actually using the data directly but that would likely just increase the demands for more uidgid definitions.

Project Atomic is a cross-Fedora/CentOS/RHEL project to make Docker and Linux containers work well. This is exactly the kind of issue I think should be discussed in that context, and tooling developed there.

To cross link, I started a thread here which has a wider audience than this ticket:

https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-January/msg00008.html

I don't think Atomic is related, really. Even without Atomic, when you run containers with plain Docker, you have the same problem. Atomic might try to solve the uid/gid issue per machine or environment but we need a solution when an image built independently can be reasonably expected to act as upgrade to previous image.

I already have

groupadd -g 389 dirsrv ; useradd -u 389 -g 389 ... dirsrv

in my Dockerfiles so my itch was scratched but I'd like the soft allocation to make sure I don't clash with others in the future, potentially leading to security issues.

Why exactly is soft allocation bad?

Why exactly is soft allocation bad?

The main problem is the scope, we have a lot more applications that store data than we have available static UID/GIDs. So if the scope is "everything that writes to disk that someone might want to put in a container", we have a problem.

I already have

groupadd -g 389 dirsrv ; useradd -u 389 -g 389 ... dirsrv

in my Dockerfiles

This seems like an ok short term solution, esp. with some communication within the Fedora cloud group or something to allocate these "image static UIDs". Longer term. though this should probably be solved by code in docker.

We might get around to discussing it again at tomorrow's meeting, if you want to add to the ticket or come to the meeting.

Replying to [comment:6 james]:

This seems like an ok short term solution, esp. with some communication within the Fedora cloud group or something to allocate these "image static UIDs".

Would fpc be able to create second list of soft static uids, for image purposes? That would likely be a superset of the general soft static list, so it might make sense for one team to manage that, so that when there is a proposal to add something to the general list, it's easier to remember check if that username/groupname already has uid/git in the image list, so use the same value.

We discussed this at today's meeting (​​http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-22/fpc.2015-01-22-17.01.txt), and we didn't feel that we should manage the image UID list:

• 474 Allocating a soft static uid and gid 389 for dirsrv (geppetto,

  
  17:24:09)
• LINK: https://fedorahosted.org/fpc/ticket/474 (geppetto, 17:24:16)
• ACTION: Managing the temporary image/container UIDs list is mostly
  out of scope for FPC, as it's going to be specific for
  atomic/cloud/whatever … and we don't want to give the impression
  this is the same as soft static UIDs. (geppetto, 17:36:51)