Add capability for snapshotters to declare support for UID remapping #7310
Conversation
This allows user namespace support to progress, either by allowing snapshotters to deal with ownership, or falling back to containerd doing a recursive chown. Signed-off-by: David Leadbeater <[email protected]> Co-authored-by: Rodrigo Campos <[email protected]>
|
Hi @dgl. Thanks for your PR. I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
/ok-to-test |
dgl
force-pushed
the
dgl/remap-id-capab
branch
2 times, most recently
from
5abb24c to
93a73f9
Compare
Signed-off-by: David Leadbeater <[email protected]>
dgl
force-pushed
the
dgl/remap-id-capab
branch
from
93a73f9 to
212852d
Compare
|
The main point I'd be interested in feedback on is the interface; I've used the labels that were there already. The other option is adding something like the |
|
Covered by rata's PR now. |
4 participants
I'm opening this as a draft, this is part of the needed support for user namespaces with Kubernetes. It lacks tests and general polish.
I've discussed this approach with @rata, it uses the existing labels used by fuse-overlayfs and makes them more general by adding a capability "remap-ids", I would like some initial thoughts on the idea.
Snapshotters would implement the capability, potentially conditionally (e.g. overlayfs would only return it if running on Linux >= 5.19).
cc @AkihiroSuda for fuse-overlayfs and @artqzn for pending PRs on related overlayfs parts.