- Packages an exploded tarball as one of the layers: skydns_sources.tar.gz
- This tarball seems to have come from a filesystem where high uids were in use:
/skydns_sources.tar.gz # ls -al
total 12
drwxr-xr-x 3 root root 4096 Oct 13 20:25 .
drwxr-xr-x 25 root root 4096 Apr 6 18:42 ..
drwxr-x--- 5 208203 5000 4096 Oct 13 18:11 skydns_sources
Having IDs outside the traditional 64k range causes issues with default
subordinate ID ranges assigned to a user. For example, in most distros
a user will be assigned a range like 100000:65536 (start:length).
When a Docker daemon using a mapping like the example above tries to map IDs
to the remapped range when unpacking image layers, given an image with uid
or gid use like the 208203 uid used above, the unpack code exits with a
mapping error.
Obviously a quick and dirty workaround is to specify a larger range for the user, which then allows high IDs to exist in images. However, someday multi-tenant installations of container clouds will want to limit per-tenant ranges to the default 64k.
skydns just happens to be an example that was brought to my attention as someone here at IBM was trying to use the image on a daemon with user namespaces enabled. I'm sure there are other images out there in registries with the same issue.