[PATCH 0/3] Enable namespaced file capabilities

Aleksa Sarai asarai at suse.de
Sun Jun 25 13:06:09 UTC 2017


>>>> 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].

> 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.

Yes, I'm aware of that -- though claiming it's purely a Docker problem 
isn't really fair (it's a problem of any container runtime that wants to 
effectively use overlay filesystems). If shiftfs is going to solve the 
sharing problem for xattrs as well, then I don't have any complaints 
other than "it sucks that we have to add more magical translation to a 
still-not-merged shiftfs".

But if you say there's not a nicer way to handle this problem, then 
that's good enough for me. :D

[1]: https://github.com/openSUSE/umoci

-- 
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/


More information about the Containers mailing list