So my essential point is that building the real kuid into the permanent
record of the xattr damages image portability, which is touted as one
of the real advantages of container images.
'container images' aren't portable in that sense now - for at least
many cases - because you have to shift the uid. However you're doing
that, you may be able to shift the xattr the same way.
Piling more things on top of that issue isn't going to make the issue easier to
solve IMO. Would shiftfs or shift-bindmounts also have to do translation of
arbitrary xattrs? Plus I would think that handling xattrs would be harder than
{u,g}ids because the image unpacker now has to be aware of all xattrs that
require remapping (Which might be an ever-growing list).
The user namespace incompatibility with the VFS's hard-coding of k{u,g}id values
in inodes is an issue that we really shouldn't be encouraging IMO [especially
given how hard it's been so far to solve that problem.]
There is one very simple solution to the problem.
Perform the unpacking in your user namespace.
I'm not aware of any major container runtime that couples image
unpacking to the runtime components. Docker hasn't done it for years
(it's split between runc and Docker/containerd). rkt hasn't ever done
it (runtime stages are totally separate to image unpacking). cri-o
doesn't do it either. I believe that only singularity does something
like that (though singularity is also not actually a "container
runtime" in the modern meaning of the term).
Not to mention that the OCI standards explicitly separate the two
concepts, and there exist tools to manipulate images that don't
explicitly use containers (or namespaces for that matter) either[1].
It doesn't require coupling it just requires knowing which uids and
gids (from the filesystem perspective) your images are going to use
when you unpack them.
Yeah, I assumed that would also work. I was just responding to "perform
the unpacking in your user namespace" and was just clarifying that
currently no container runtime would want to do that.
And all of that can work as an unprivileged user if done carefully.
Which should reduce the possibility of danger.
:+1: I'm definitely going to be using this within umoci's rootless
containers support as well as anywhere else it's appropriate.
Cheers.
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
