Date:   Fri, 16 Jun 2017 11:02:58 +0200 (CEST)
From:   Christian Brauner <christian.brauner@...lbox.org>
To:     "Serge E. Hallyn" <serge@...lyn.com>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>
Cc:     containers@...ts.linux-foundation.org, xiaolong.ye@...el.com,
        Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...org,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH v4] Introduce v3 namespaced file capabilities

> "Serge E. Hallyn" <serge@...lyn.com> hat am 15. Juni 2017 um 05:05 geschrieben:
> 
> 
> On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:
> > On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:
> > >Quoting Stefan Berger (stefanb@...ux.vnet.ibm.com):
> > >>  If all extended
> > >>attributes were to support this model, maybe the 'uid' could be
> > >>associated with the 'name' of the xattr rather than its 'value' (not
> > >>sure whether that's possible).
> > >Right, I missed that in your original email when I saw it this morning.
> > >It's not what my patch does, but it's an interesting idea.  Do you have
> > >a patch to that effect?  We might even be able to generalize that to
> > 
> > No, I don't have a patch. It may not be possible to implement it.
> > The xattr_handler's  take the name of the xattr as input to get().
> 
> That may be ok though.  Assume the host created a container with
> 100000 as the uid for root, which created a container with 130000 as
> uid for root.  If root in the nested container tries to read the
> xattr, the kernel can check for security.foo[130000] first, then
> security.foo[100000], then security.foo.  Or, it can do a listxattr
> and look for those.  Am I overlooking one?
> 
> > So one could try to encode the mapped uid in the name. However, that
> 
> I thought that's exactly what you were suggesting in your original
> email?  "security.capability[uid=2000]"
> 
> > could lead to problems with stale xattrs in a shared filesystem over
> > time unless one could limit the number of xattrs with the same
> > prefix, e.g., security.capability*. So I doubt that it would work.
> 
> Hm.  Yeah.  But really how many setups are there like that?  I.e. if
> you launch a regular docker or lxd container, the image doesn't do a
> bind mount of a shared image, it layers something above it or does a
> copy.  What setups do you know of where multiple containers in different
> user namespaces mount the same filesystem shared and writeable?

Iiuc, this should also be something that will be addressed by a viable shifts
solution so it's probably not worth worrying about it here. I was going to
point out that there are plans of sharing filesystems between containers
in different user namespaces. However, without shifts this really will only
work nicely if the container's setup identical id mappings in which case you
won't have to worry about stale xattrs.

> 
> > Otherwise it would be good if the value was wrapped in a data
> > structure use by all xattrs, but that doesn't seem to be the case,
> > either. So I guess we have to go into each type of value structure
> > and add a uid field there.
> > 
> > >namespace any security.* xattrs.  Wouldn't be automatically enabled
> > >for anything but ima and capabilities, but we could make the infrastructure
> > >generic and re-usable.
> > >
> _______________________________________________
> Containers mailing list
> Containers@...ts.linux-foundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/containers

Powered by blists - more mailing lists