[20.10 backport] Use v2 capabilities in layer archives #42352
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick #41724
- What I did
Fixes #41723
When building images in a user-namespaced container, v3 capabilities are
stored including the root UID of the creator of the user-namespace.
This UID does not make sense outside the build environment however. If
the image is run in a non-user-namespaced runtime, or if a user-namespaced
runtime uses a different UID, the capabilities requested by the effective
bit will not be honoured by
execve(2)
due to this mismatch.Instead, we convert v3 capabilities to v2, dropping the root UID on the
fly.
- How I did it
Patched
ReadSecurityXattrToTarHeader()
to automatically convert v3 capabilities to v2 by switching the version identifier and dropping the root UID data.- How to verify it
This reproducer can be used.
Compared with the output in issue #41723 this produces:
So we see that in the 2nd case also
execve(2)
honoured the effective bit.- Description for the changelog
Capabilities in image layers are stored in v2 format even when built inside a non-root user-namespace.
- A picture of a cute animal (not mandatory but encouraged)