With userns-remap, the layers of another build stage or image are
stored with host (remapped) IDs. Yet the classic builder copies files
from such a source using an archiver with the daemon ID mapping, which
treats the file owner IDs as container IDs and maps them again.
As a result, COPY --from of a file owned by a non-root user fails with
an error like "container ID 100100 cannot be mapped to a host ID".
Files owned by the remapped root only work because of a special case
in IdentityMapping.ToHost, which skips mapping the IDs equal to the
remapped root ones. That special case is wrong in itself, and fixing
it would break COPY --from for all files.
Fix by using an archiver without ID mapping when copying from another
build stage or image. Since such an archiver creates new directories
owned by the host root, create the destination directory and its parents
beforehand, owned by the remapped root (if chown is requested, the newly
created destination directory is chowned later, as before).
Similarly, when copying a single file with ownership preserved, create
its new parent directories owned by the remapped root. Previously, they
were owned by the host root.
Add a test case.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Kir Kolyshkin
c3f57a158f