diff for duplicates of <20170620195750.GA5807@redhat.com> diff --git a/a/1.txt b/N1/1.txt index a78058e..67b669c 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -3,11 +3,11 @@ On Tue, Jun 20, 2017 at 08:42:45AM +0300, Amir Goldstein wrote: > <ebiederm@xmission.com> wrote: > > "Serge E. Hallyn" <serge@hallyn.com> writes: > > -> >> Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com): +> >> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com): > >>> On 06/14/2017 11:05 PM, Serge E. Hallyn wrote: > >>> >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(a)linux.vnet.ibm.com): +> >>> >>>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 @@ -45,25 +45,25 @@ On Tue, Jun 20, 2017 at 08:42:45AM +0300, Amir Goldstein wrote: > >> Thanks! > >> > >>> Encoding of uid is in the attribute name now as follows: -> >>> security.foo(a)uid=<uid> +> >>> security.foo@uid=<uid> > >>> > >>> 1) The 'plain' security.capability is only r/w accessible from the > >>> host (init_user_ns). > >>> 2) When userns reads/writes 'security.capability' it will read/write -> >>> security.capability(a)uid=<uid> instead, with uid being the uid of +> >>> security.capability@uid=<uid> instead, with uid being the uid of > >>> root , e.g. 1000. > >>> 3) When listing xattrs for userns the host's security.capability is > >>> filtered out to avoid read failures iof 'security.capability' if -> >>> security.capability(a)uid=<uid> is read but not there. (see 1) and 2)) +> >>> security.capability@uid=<uid> is read but not there. (see 1) and 2)) > >>> 4) security.capability* may all be read from anywhere -> >>> 5) security.capability(a)uid=<uid> may be read or written directly +> >>> 5) security.capability@uid=<uid> may be read or written directly > >>> from a userns if <uid> matches the uid of root (current_uid()) > >> > >> This looks very close to what we want. One exception - we do want > >> to support root in a user namespace being able to write -> >> security.capability(a)uid=<x> where <x> is a valid uid mapped in its +> >> security.capability@uid=<x> where <x> is a valid uid mapped in its > >> namespace. In that case the name should be rewritten to be -> >> security.capability(a)uid=<y> where y is the unmapped kuid.val. +> >> security.capability@uid=<y> where y is the unmapped kuid.val. > >> > >> Eric, > >> @@ -79,7 +79,7 @@ On Tue, Jun 20, 2017 at 08:42:45AM +0300, Amir Goldstein wrote: > > Apropos stackable filesystems [cc some overlayfs folks], is there any > way that parts of this work could be generalized towards ns aware -> trusted(a)uid.* xattr? +> trusted@uid.* xattr? > > With overlayfs, files are written to underlying fs with mounter's > credentials. @@ -95,7 +95,7 @@ Given we switch to mounter's creds for operations on underlying filesystem (setxattr, getxattr), I thought that it probably will call xattr_userns_name() in nested manner. Once using tasks's creds and second time using mounter's creds. So that probably -should have made it security.foo(a)uid@uid. I tried patches quickly +should have made it security.foo@uid@uid. I tried patches quickly but setcap/getcap inside containers work. So may be it is due to the fact that mounting was done from init_user_ns and following line of code will avoid adding @uid in that case. diff --git a/a/content_digest b/N1/content_digest index c0f47f5..558662c 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,20 +1,38 @@ + "ref\09f80188c-df03-066a-5dac-785cc711d064@linux.vnet.ibm.com\0" + "ref\020170613171818.GA9070@mail.hallyn.com\0" + "ref\074e490f3-3c47-abfa-86ae-0fa0d1ddb43a@linux.vnet.ibm.com\0" + "ref\020170613235521.GC15685@mail.hallyn.com\0" + "ref\0ce471b11-e76a-25f3-eae8-eca30e7233af@linux.vnet.ibm.com\0" + "ref\020170615030543.GA8979@mail.hallyn.com\0" + "ref\0f0df1914-bca2-31a0-cdba-df30d85d70b3@linux.vnet.ibm.com\0" + "ref\020170618221418.GA364@mail.hallyn.com\0" + "ref\087tw3boe5d.fsf@xmission.com\0" "ref\0CAOQ4uxhi5fezF7e9FpS=hHUb1LqzyCNq9BcG14RV_Srj1hS-Vw@mail.gmail.com\0" "From\0Vivek Goyal <vgoyal@redhat.com>\0" "Subject\0Re: [PATCH v4] Introduce v3 namespaced file capabilities\0" "Date\0Tue, 20 Jun 2017 15:57:50 -0400\0" - "To\0lkp@lists.01.org\0" - "\01:1\0" + "To\0Amir Goldstein <amir73il@gmail.com>\0" + "Cc\0Eric W. Biederman <ebiederm@xmission.com>" + Serge E. Hallyn <serge@hallyn.com> + Stefan Berger <stefanb@linux.vnet.ibm.com> + Mimi Zohar <zohar@linux.vnet.ibm.com> + Linux Containers <containers@lists.linux-foundation.org> + LKML <linux-kernel@vger.kernel.org> + xiaolong.ye@intel.com + lkp@01.org + " Miklos Szeredi <miklos@szeredi.hu>\0" + "\00:1\0" "b\0" "On Tue, Jun 20, 2017 at 08:42:45AM +0300, Amir Goldstein wrote:\n" "> On Tue, Jun 20, 2017 at 12:34 AM, Eric W. Biederman\n" "> <ebiederm@xmission.com> wrote:\n" "> > \"Serge E. Hallyn\" <serge@hallyn.com> writes:\n" "> >\n" - "> >> Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):\n" + "> >> Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):\n" "> >>> On 06/14/2017 11:05 PM, Serge E. Hallyn wrote:\n" "> >>> >On Wed, Jun 14, 2017 at 08:27:40AM -0400, Stefan Berger wrote:\n" "> >>> >>On 06/13/2017 07:55 PM, Serge E. Hallyn wrote:\n" - "> >>> >>>Quoting Stefan Berger (stefanb(a)linux.vnet.ibm.com):\n" + "> >>> >>>Quoting Stefan Berger (stefanb@linux.vnet.ibm.com):\n" "> >>> >>>> If all extended\n" "> >>> >>>>attributes were to support this model, maybe the 'uid' could be\n" "> >>> >>>>associated with the 'name' of the xattr rather than its 'value' (not\n" @@ -52,25 +70,25 @@ "> >> Thanks!\n" "> >>\n" "> >>> Encoding of uid is in the attribute name now as follows:\n" - "> >>> security.foo(a)uid=<uid>\n" + "> >>> security.foo@uid=<uid>\n" "> >>>\n" "> >>> 1) The 'plain' security.capability is only r/w accessible from the\n" "> >>> host (init_user_ns).\n" "> >>> 2) When userns reads/writes 'security.capability' it will read/write\n" - "> >>> security.capability(a)uid=<uid> instead, with uid being the uid of\n" + "> >>> security.capability@uid=<uid> instead, with uid being the uid of\n" "> >>> root , e.g. 1000.\n" "> >>> 3) When listing xattrs for userns the host's security.capability is\n" "> >>> filtered out to avoid read failures iof 'security.capability' if\n" - "> >>> security.capability(a)uid=<uid> is read but not there. (see 1) and 2))\n" + "> >>> security.capability@uid=<uid> is read but not there. (see 1) and 2))\n" "> >>> 4) security.capability* may all be read from anywhere\n" - "> >>> 5) security.capability(a)uid=<uid> may be read or written directly\n" + "> >>> 5) security.capability@uid=<uid> may be read or written directly\n" "> >>> from a userns if <uid> matches the uid of root (current_uid())\n" "> >>\n" "> >> This looks very close to what we want. One exception - we do want\n" "> >> to support root in a user namespace being able to write\n" - "> >> security.capability(a)uid=<x> where <x> is a valid uid mapped in its\n" + "> >> security.capability@uid=<x> where <x> is a valid uid mapped in its\n" "> >> namespace. In that case the name should be rewritten to be\n" - "> >> security.capability(a)uid=<y> where y is the unmapped kuid.val.\n" + "> >> security.capability@uid=<y> where y is the unmapped kuid.val.\n" "> >>\n" "> >> Eric,\n" "> >>\n" @@ -86,7 +104,7 @@ "> \n" "> Apropos stackable filesystems [cc some overlayfs folks], is there any\n" "> way that parts of this work could be generalized towards ns aware\n" - "> trusted(a)uid.* xattr?\n" + "> trusted@uid.* xattr?\n" "> \n" "> With overlayfs, files are written to underlying fs with mounter's\n" "> credentials.\n" @@ -102,7 +120,7 @@ "filesystem (setxattr, getxattr), I thought that it probably\n" "will call xattr_userns_name() in nested manner. Once using tasks's\n" "creds and second time using mounter's creds. So that probably\n" - "should have made it security.foo(a)uid@uid. I tried patches quickly\n" + "should have made it security.foo@uid@uid. I tried patches quickly\n" "but setcap/getcap inside containers work. So may be it is\n" "due to the fact that mounting was done from init_user_ns and\n" "following line of code will avoid adding @uid in that case.\n" @@ -122,4 +140,4 @@ "\n" Vivek -5d224b87a15d58200f93a4eda0094c6cd633b0505dd63b50605abf7ffd2429a6 +44aa9924a693aa5cd66648a2946583d81c92c81fc6ee273fa09a42cafd1a391d
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.