Single-ID images
Table of contents
- What are the challenges that we are trying to solve?
- What ideas do we have for how to address these challenges?
- How do these ideas break down into…
- Questions?
- What pre-existing work or software can support these ideas?
- Relevant OCI Issues
What are the challenges that we are trying to solve?
Fully unprivileged container implementations, with no setuid/setgid/setcap binaries and no use of privileged helpers to set up namespaces, are both possible and a valid/important use case. In HPC this supports container use and building by normal users on the hardware where they will actually run.
OCI currently assumes that arbitrary UIDs and GIDs in image layers will be preserved. This is not the case with fully unprivileged containers, which have access only to a single UID and a small number of GIDs that are not preserved across different container runs — they can be arbitrary but are just aliases of the invoking user’s IDs.
Similarly, images generated by fully unprivileged builds don’t have meaningful IDs; they might be those of the invoking user or reset to something arbitrary to avoid leaking internal IDs (Charliecloud uses 0:0).
(Details and subtleties on all this in Minimizing privilege for building HPC containers, by Priedhorsky, Canon, Randles and Younge.)
What ideas do we have for how to address these challenges?
-
Flag to mark such images as ID-flattened. Possible values: no valid IDs, valid IDs but flattening OK (default), valid IDs but flatten with caution. Perhaps the last one warns or requires confirmation. I hesitate to include a valid IDs and do not flatten because I worry it will be abused. Certainly, if that value was in the spec I’d want to add a
ch-image(1)flag to override it. -
Behave like
tar(1): change file ownership to the invoking user on unpacking.
How do these ideas break down into…
Already existing OCI specs?
A new project (CNCF or OCI)
Questions?
What pre-existing work or software can support these ideas?
tar(1) addressed this problem a long time ago by ignoring the UID/GID of
files within the archive and substituting the calling user’s when invoked by
unprivileged users.
As a fully unprivileged runtime, Charliecloud already flattens IDs throughout its workflow.