Re: [PATCH 0/3] Enable namespaced file capabilities

["Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>]

Quoting Aleksa Sarai (asarai-l3A5Bk7waGM@public.gmane.org):
> >>>>>>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.

That's exactly what lxc does.