Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752557AbdFODFp (ORCPT ); Wed, 14 Jun 2017 23:05:45 -0400 Received: from h2.hallyn.com ([78.46.35.8]:45548 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752073AbdFODFn (ORCPT ); Wed, 14 Jun 2017 23:05:43 -0400 Date: Wed, 14 Jun 2017 22:05:43 -0500 From: "Serge E. Hallyn" To: Stefan Berger Cc: "Serge E. Hallyn" , "Eric W. Biederman" , Masami Ichikawa , containers@lists.linux-foundation.org, lkp@01.org, xiaolong.ye@intel.com, LKML , Mimi Zohar Subject: Re: [PATCH v4] Introduce v3 namespaced file capabilities Message-ID: <20170615030543.GA8979@mail.hallyn.com> References: <20170507092105.GA67584@inn.lkp.intel.com> <20170508044408.GA11400@mail.hallyn.com> <20170508181156.GA23112@mail.hallyn.com> <9f80188c-df03-066a-5dac-785cc711d064@linux.vnet.ibm.com> <20170613171818.GA9070@mail.hallyn.com> <74e490f3-3c47-abfa-86ae-0fa0d1ddb43a@linux.vnet.ibm.com> <20170613235521.GC15685@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2249 Lines: 45 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@linux.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? > 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. > >