Hello,
for containerization of FreeIPA, we'd need static uid/gid for dirsrv because it creates data that will be stored in volumes and we need different versions of the software to run under the same uid to be able to access the data. Soft static allocation will prevent clashes in the future.
We propose uid/gid 389 which based on /usr/share/doc/setup/uidgid in setup-2.9.0-2.fc21.noarch is unused.
Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1143066
Thank you,
Jan
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.
...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?
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
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:
Metadata Update from @james: - Issue assigned to james
Log in to comment on this ticket.