Aleksa Sarai <asarai@xxxxxxx> writes:
>>> 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.
The reason Docker doesn't do that is they want to share files and images
between different containers. That sharing when we are talking about
different privilege domains and persistent storage is a challenge.
Hopefully shiftfs can solve that challenge.
When you stop trying to share between privilege domain this is all quite
trivial. This is not an incompatibility of the VFS.
Eric
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/containers
