From: Casey Schaufler <casey@schaufler-ca.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Amir Goldstein <amir73il@gmail.com>,
Stefan Berger <stefanb@linux.vnet.ibm.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Linux Containers <containers@lists.linux-foundation.org>,
lkp@01.org, xiaolong.ye@intel.com,
linux-kernel <linux-kernel@vger.kernel.org>,
Mimi Zohar <zohar@linux.vnet.ibm.com>,
Tycho Andersen <tycho@docker.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
christian.brauner@mailbox.org, Vivek Goyal <vgoyal@redhat.com>,
LSM List <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH 0/3] Enable namespaced file capabilities
Date: Fri, 23 Jun 2017 09:53:43 -0700 [thread overview]
Message-ID: <ef37880d-6baa-12a6-eab1-bcd0a4e94d53@schaufler-ca.com> (raw)
In-Reply-To: <20170623163030.GA18820@mail.hallyn.com>
On 6/23/2017 9:30 AM, Serge E. Hallyn wrote:
> Quoting Casey Schaufler (casey@schaufler-ca.com):
>> On 6/23/2017 9:00 AM, Serge E. Hallyn wrote:
>>> Quoting Amir Goldstein (amir73il@gmail.com):
>>>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>>>> <stefanb@linux.vnet.ibm.com> wrote:
>>>>> This series of patches primary goal is to enable file capabilities
>>>>> in user namespaces without affecting the file capabilities that are
>>>>> effective on the host. This is to prevent that any unprivileged user
>>>>> on the host maps his own uid to root in a private namespace, writes
>>>>> the xattr, and executes the file with privilege on the host.
>>>>>
>>>>> We achieve this goal by writing extended attributes with a different
>>>>> name when a user namespace is used. If for example the root user
>>>>> in a user namespace writes the security.capability xattr, the name
>>>>> of the xattr that is actually written is encoded as
>>>>> security.capability@uid=1000 for root mapped to uid 1000 on the host.
>>>>> When listing the xattrs on the host, the existing security.capability
>>>>> as well as the security.capability@uid=1000 will be shown. Inside the
>>>>> namespace only 'security.capability', with the value of
>>>>> security.capability@uid=1000, is visible.
>>>>>
>>>> Am I the only one who thinks that suffix is perhaps not the best grammar
>>>> to use for this namespace?
>>> You're the only one to have mentioned it so far.
>>>
>>>> xattrs are clearly namespaced by prefix, so it seems right to me to keep
>>>> it that way - define a new special xattr namespace "ns" and only if that
>>>> prefix exists, the @uid suffix will be parsed.
>>>> This could be either ns.security.capability@uid=1000 or
>>>> ns@uid=1000.security.capability. The latter seems more correct to me,
>>>> because then we will be able to namespace any xattr without having to
>>>> protect from "unprivileged xattr injection", i.e.:
>>>> setfattr -n "user.whatever.foo@uid=0"
>>> I like it for simplifying the parser code. One concern I have is that,
>>> since ns.* is currently not gated, one could write ns.* on an older
>>> kernel and then exploit it on a newer one.
>> security.ns.capability@uid=1000, then?
> That loses the advantage of simpler parsing though. (Really it's not much
> of a simplification anyway.) So I'm not sure what advantage remains.
>
>> Or maybe just security.ns.capability, taking James' comment into account.
> That last one may be suitable as an option, useful for his particular
> (somewhat barbaric :) use case, but it's not ok for the general solution.
security.ns@uid=100.capability
It makes the namespace part explicit and separate from
the rest of the attribute name. It also generalizes for
other attributes.
security.ns@uid=1000@smack=WestOfOne.SMACK64
> If uid 1000 was delegated the subuids 100000-199999, it should be able
> to write a file capability for use by his subuids, but that file capability
> must not apply to other subuids.
>
> -serge
>
WARNING: multiple messages have this Message-ID (diff)
From: casey@schaufler-ca.com (Casey Schaufler)
To: linux-security-module@vger.kernel.org
Subject: [PATCH 0/3] Enable namespaced file capabilities
Date: Fri, 23 Jun 2017 09:53:43 -0700 [thread overview]
Message-ID: <ef37880d-6baa-12a6-eab1-bcd0a4e94d53@schaufler-ca.com> (raw)
In-Reply-To: <20170623163030.GA18820@mail.hallyn.com>
On 6/23/2017 9:30 AM, Serge E. Hallyn wrote:
> Quoting Casey Schaufler (casey at schaufler-ca.com):
>> On 6/23/2017 9:00 AM, Serge E. Hallyn wrote:
>>> Quoting Amir Goldstein (amir73il at gmail.com):
>>>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>>>> <stefanb@linux.vnet.ibm.com> wrote:
>>>>> This series of patches primary goal is to enable file capabilities
>>>>> in user namespaces without affecting the file capabilities that are
>>>>> effective on the host. This is to prevent that any unprivileged user
>>>>> on the host maps his own uid to root in a private namespace, writes
>>>>> the xattr, and executes the file with privilege on the host.
>>>>>
>>>>> We achieve this goal by writing extended attributes with a different
>>>>> name when a user namespace is used. If for example the root user
>>>>> in a user namespace writes the security.capability xattr, the name
>>>>> of the xattr that is actually written is encoded as
>>>>> security.capability at uid=1000 for root mapped to uid 1000 on the host.
>>>>> When listing the xattrs on the host, the existing security.capability
>>>>> as well as the security.capability at uid=1000 will be shown. Inside the
>>>>> namespace only 'security.capability', with the value of
>>>>> security.capability at uid=1000, is visible.
>>>>>
>>>> Am I the only one who thinks that suffix is perhaps not the best grammar
>>>> to use for this namespace?
>>> You're the only one to have mentioned it so far.
>>>
>>>> xattrs are clearly namespaced by prefix, so it seems right to me to keep
>>>> it that way - define a new special xattr namespace "ns" and only if that
>>>> prefix exists, the @uid suffix will be parsed.
>>>> This could be either ns.security.capability at uid=1000 or
>>>> ns at uid=1000.security.capability. The latter seems more correct to me,
>>>> because then we will be able to namespace any xattr without having to
>>>> protect from "unprivileged xattr injection", i.e.:
>>>> setfattr -n "user.whatever.foo at uid=0"
>>> I like it for simplifying the parser code. One concern I have is that,
>>> since ns.* is currently not gated, one could write ns.* on an older
>>> kernel and then exploit it on a newer one.
>> security.ns.capability at uid=1000, then?
> That loses the advantage of simpler parsing though. (Really it's not much
> of a simplification anyway.) So I'm not sure what advantage remains.
>
>> Or maybe just security.ns.capability, taking James' comment into account.
> That last one may be suitable as an option, useful for his particular
> (somewhat barbaric :) use case, but it's not ok for the general solution.
security.ns at uid=100.capability
It makes the namespace part explicit and separate from
the rest of the attribute name. It also generalizes for
other attributes.
security.ns at uid=1000 at smack=WestOfOne.SMACK64
> If uid 1000 was delegated the subuids 100000-199999, it should be able
> to write a file capability for use by his subuids, but that file capability
> must not apply to other subuids.
>
> -serge
>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Casey Schaufler <casey@schaufler-ca.com>
To: lkp@lists.01.org
Subject: Re: [PATCH 0/3] Enable namespaced file capabilities
Date: Fri, 23 Jun 2017 09:53:43 -0700 [thread overview]
Message-ID: <ef37880d-6baa-12a6-eab1-bcd0a4e94d53@schaufler-ca.com> (raw)
In-Reply-To: <20170623163030.GA18820@mail.hallyn.com>
[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]
On 6/23/2017 9:30 AM, Serge E. Hallyn wrote:
> Quoting Casey Schaufler (casey(a)schaufler-ca.com):
>> On 6/23/2017 9:00 AM, Serge E. Hallyn wrote:
>>> Quoting Amir Goldstein (amir73il(a)gmail.com):
>>>> On Thu, Jun 22, 2017 at 9:59 PM, Stefan Berger
>>>> <stefanb@linux.vnet.ibm.com> wrote:
>>>>> This series of patches primary goal is to enable file capabilities
>>>>> in user namespaces without affecting the file capabilities that are
>>>>> effective on the host. This is to prevent that any unprivileged user
>>>>> on the host maps his own uid to root in a private namespace, writes
>>>>> the xattr, and executes the file with privilege on the host.
>>>>>
>>>>> We achieve this goal by writing extended attributes with a different
>>>>> name when a user namespace is used. If for example the root user
>>>>> in a user namespace writes the security.capability xattr, the name
>>>>> of the xattr that is actually written is encoded as
>>>>> security.capability(a)uid=1000 for root mapped to uid 1000 on the host.
>>>>> When listing the xattrs on the host, the existing security.capability
>>>>> as well as the security.capability(a)uid=1000 will be shown. Inside the
>>>>> namespace only 'security.capability', with the value of
>>>>> security.capability(a)uid=1000, is visible.
>>>>>
>>>> Am I the only one who thinks that suffix is perhaps not the best grammar
>>>> to use for this namespace?
>>> You're the only one to have mentioned it so far.
>>>
>>>> xattrs are clearly namespaced by prefix, so it seems right to me to keep
>>>> it that way - define a new special xattr namespace "ns" and only if that
>>>> prefix exists, the @uid suffix will be parsed.
>>>> This could be either ns.security.capability(a)uid=1000 or
>>>> ns(a)uid=1000.security.capability. The latter seems more correct to me,
>>>> because then we will be able to namespace any xattr without having to
>>>> protect from "unprivileged xattr injection", i.e.:
>>>> setfattr -n "user.whatever.foo(a)uid=0"
>>> I like it for simplifying the parser code. One concern I have is that,
>>> since ns.* is currently not gated, one could write ns.* on an older
>>> kernel and then exploit it on a newer one.
>> security.ns.capability(a)uid=1000, then?
> That loses the advantage of simpler parsing though. (Really it's not much
> of a simplification anyway.) So I'm not sure what advantage remains.
>
>> Or maybe just security.ns.capability, taking James' comment into account.
> That last one may be suitable as an option, useful for his particular
> (somewhat barbaric :) use case, but it's not ok for the general solution.
security.ns(a)uid=100.capability
It makes the namespace part explicit and separate from
the rest of the attribute name. It also generalizes for
other attributes.
security.ns(a)uid=1000(a)smack=WestOfOne.SMACK64
> If uid 1000 was delegated the subuids 100000-199999, it should be able
> to write a file capability for use by his subuids, but that file capability
> must not apply to other subuids.
>
> -serge
>
next prev parent reply other threads:[~2017-06-23 16:53 UTC|newest]
Thread overview: 180+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-22 18:59 [PATCH 0/3] Enable namespaced file capabilities Stefan Berger
2017-06-22 18:59 ` Stefan Berger
2017-06-22 18:59 ` Stefan Berger
2017-06-22 18:59 ` [PATCH 1/3] xattr: Enable security.capability in user namespaces Stefan Berger
2017-06-22 18:59 ` Stefan Berger
2017-06-22 18:59 ` Stefan Berger
2017-06-24 21:02 ` kbuild test robot
2017-06-24 21:02 ` kbuild test robot
2017-06-24 21:02 ` kbuild test robot
[not found] ` <1498157989-11814-2-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-24 21:02 ` [PATCH] xattr: fix kstrdup.cocci warnings kbuild test robot
2017-06-24 21:02 ` [PATCH 1/3] xattr: Enable security.capability in user namespaces kbuild test robot
2017-06-24 21:02 ` [PATCH] xattr: fix kstrdup.cocci warnings kbuild test robot
2017-06-24 21:02 ` kbuild test robot
2017-06-24 21:02 ` kbuild test robot
[not found] ` <1498157989-11814-1-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-22 18:59 ` [PATCH 1/3] xattr: Enable security.capability in user namespaces Stefan Berger
2017-06-22 18:59 ` [PATCH 2/3] Enable capabilities of files from shared filesystem Stefan Berger
2017-06-22 18:59 ` Stefan Berger
2017-06-22 18:59 ` Stefan Berger
2017-06-22 18:59 ` Stefan Berger
2017-06-22 18:59 ` [PATCH 3/3] Enable security.selinux in user namespaces Stefan Berger
2017-06-22 19:59 ` [PATCH 0/3] Enable namespaced file capabilities Casey Schaufler
2017-06-22 23:29 ` James Bottomley
2017-06-23 7:01 ` Amir Goldstein
2017-06-23 7:01 ` Amir Goldstein
2017-06-23 7:01 ` Amir Goldstein
2017-06-23 16:00 ` Serge E. Hallyn
2017-06-23 16:00 ` Serge E. Hallyn
2017-06-23 16:00 ` Serge E. Hallyn
[not found] ` <20170623160026.GA18257-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 16:16 ` Casey Schaufler
2017-06-23 16:16 ` Casey Schaufler
2017-06-23 16:16 ` Casey Schaufler
2017-06-23 16:16 ` Casey Schaufler
[not found] ` <aa62373e-7cd6-39dd-2e38-2b6d6dbe18a8-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-23 16:30 ` Serge E. Hallyn
2017-06-23 18:08 ` Stefan Berger
2017-06-23 16:30 ` Serge E. Hallyn
2017-06-23 16:30 ` Serge E. Hallyn
2017-06-23 16:53 ` Casey Schaufler [this message]
2017-06-23 16:53 ` Casey Schaufler
2017-06-23 16:53 ` Casey Schaufler
2017-06-23 17:01 ` Serge E. Hallyn
2017-06-23 17:01 ` Serge E. Hallyn
2017-06-23 17:49 ` Eric W. Biederman
2017-06-23 17:49 ` Eric W. Biederman
2017-06-23 17:49 ` Eric W. Biederman
[not found] ` <8760fmh9vc.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-06-23 18:32 ` Serge E. Hallyn
2017-06-23 18:32 ` Serge E. Hallyn
2017-06-23 18:32 ` Serge E. Hallyn
[not found] ` <20170623170108.GA19354-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 17:49 ` Eric W. Biederman
[not found] ` <ef37880d-6baa-12a6-eab1-bcd0a4e94d53-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-23 17:01 ` Serge E. Hallyn
2017-06-23 17:07 ` James Bottomley
2017-06-23 17:07 ` James Bottomley
2017-06-23 17:07 ` James Bottomley
[not found] ` <1498237641.3641.15.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-06-23 17:18 ` Aleksa Sarai
[not found] ` <b57803da-0e8b-594d-901b-12eb509f04b5-l3A5Bk7waGM@public.gmane.org>
2017-06-23 18:22 ` Serge E. Hallyn
2017-06-23 17:20 ` Serge E. Hallyn
2017-06-23 17:20 ` Serge E. Hallyn
2017-06-23 17:20 ` Serge E. Hallyn
[not found] ` <20170623172016.GA19551-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 17:28 ` Aleksa Sarai
[not found] ` <553a72c4-eda9-52d6-2ae2-f8687c0c7c70-l3A5Bk7waGM@public.gmane.org>
2017-06-23 18:30 ` Serge E. Hallyn
2017-06-25 12:35 ` Eric W. Biederman
[not found] ` <87lgogdz2t.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-06-25 13:06 ` Aleksa Sarai
[not found] ` <f1716e8c-dba8-a051-6bc7-285f13ffcaf0-l3A5Bk7waGM@public.gmane.org>
2017-06-25 13:28 ` Eric W. Biederman
[not found] ` <87zicwb3hu.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-06-25 13:51 ` Aleksa Sarai
[not found] ` <5bef361a-bc31-f3bc-f513-e728a48f0524-l3A5Bk7waGM@public.gmane.org>
2017-06-25 16:45 ` Serge E. Hallyn
[not found] ` <20170625164558.GA24471-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-26 6:14 ` Aleksa Sarai
2017-06-23 17:38 ` Stefan Berger
2017-06-23 17:38 ` Stefan Berger
2017-06-23 17:38 ` Stefan Berger
2017-06-23 17:38 ` Stefan Berger
[not found] ` <d288ea69-adec-f257-30cb-b1d9c57c996b-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-23 18:34 ` Serge E. Hallyn
2017-06-23 18:34 ` Serge E. Hallyn
2017-06-23 18:34 ` Serge E. Hallyn
[not found] ` <20170623163030.GA18820-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 16:53 ` Casey Schaufler
2017-06-23 17:07 ` James Bottomley
2017-06-23 18:08 ` Stefan Berger
2017-06-23 18:08 ` Stefan Berger
2017-06-23 18:08 ` Stefan Berger
[not found] ` <3404c486-c848-3283-50f7-2283cb631e8e-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-23 18:35 ` Serge E. Hallyn
2017-06-23 18:35 ` Serge E. Hallyn
2017-06-23 18:35 ` Serge E. Hallyn
[not found] ` <20170623183520.GC21137-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 20:30 ` Casey Schaufler
2017-06-23 20:30 ` Casey Schaufler
2017-06-23 20:30 ` Casey Schaufler
2017-06-23 20:30 ` Casey Schaufler
2017-06-23 23:09 ` Stefan Berger
2017-06-23 23:09 ` Stefan Berger
2017-06-23 23:09 ` Stefan Berger
2017-06-23 23:09 ` Stefan Berger
[not found] ` <da083027-fcd4-bc08-2d88-93034ba1cacc-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-23 23:51 ` Casey Schaufler
2017-06-23 23:51 ` Casey Schaufler
2017-06-23 23:51 ` Casey Schaufler
2017-06-23 23:51 ` Casey Schaufler
2017-06-28 5:41 ` Serge E. Hallyn
2017-06-28 5:41 ` Serge E. Hallyn
2017-06-28 5:41 ` Serge E. Hallyn
[not found] ` <20170628054138.GA15939-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-28 7:18 ` Amir Goldstein
2017-06-28 7:18 ` Amir Goldstein
2017-06-28 7:18 ` Amir Goldstein
2017-06-28 14:04 ` Stefan Berger
2017-06-28 14:04 ` Stefan Berger
2017-06-28 14:04 ` Stefan Berger
[not found] ` <CAOQ4uxhiSHEXzWN7=g-nmu=ebpv7hkXszW03JZ4UJkcjTeH+oQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-06-28 14:04 ` Stefan Berger
2017-06-28 14:28 ` Serge E. Hallyn
2017-06-28 14:28 ` Serge E. Hallyn
2017-06-28 14:28 ` Serge E. Hallyn
2017-06-28 14:28 ` Serge E. Hallyn
2017-06-23 20:09 ` Vivek Goyal
2017-06-23 20:09 ` Vivek Goyal
2017-06-23 20:09 ` Vivek Goyal
2017-06-23 20:09 ` Vivek Goyal
[not found] ` <20170623200956.GB24779-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-06-23 20:17 ` Serge E. Hallyn
2017-06-23 20:17 ` Serge E. Hallyn
2017-06-23 20:17 ` Serge E. Hallyn
2017-06-23 20:36 ` Vivek Goyal
2017-06-23 20:36 ` Vivek Goyal
2017-06-23 20:36 ` Vivek Goyal
2017-06-23 20:51 ` Serge E. Hallyn
2017-06-23 20:51 ` Serge E. Hallyn
[not found] ` <20170623203643.GC24779-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-06-23 20:51 ` Serge E. Hallyn
[not found] ` <20170623201723.GA22857-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 20:36 ` Vivek Goyal
2017-06-22 18:59 ` [PATCH 3/3] Enable security.selinux in user namespaces Stefan Berger
2017-06-22 18:59 ` Stefan Berger
2017-06-22 18:59 ` Stefan Berger
[not found] ` <1498157989-11814-4-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-23 20:30 ` Stephen Smalley
2017-06-23 20:30 ` Stephen Smalley
2017-06-23 20:30 ` Stephen Smalley
2017-06-23 20:30 ` Stephen Smalley
[not found] ` <1498249800.2063.9.camel-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>
2017-06-23 23:41 ` Stefan Berger
2017-06-23 23:41 ` Stefan Berger
2017-06-23 23:41 ` Stefan Berger
2017-06-23 23:41 ` Stefan Berger
2017-06-22 19:59 ` [PATCH 0/3] Enable namespaced file capabilities Casey Schaufler
2017-06-22 19:59 ` Casey Schaufler
2017-06-22 19:59 ` Casey Schaufler
2017-06-22 20:12 ` Stefan Berger
2017-06-22 20:12 ` Stefan Berger
2017-06-22 20:12 ` Stefan Berger
[not found] ` <10fb9c1b-e9af-336c-9a1b-cf95259cfaf3-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-22 20:33 ` Casey Schaufler
2017-06-22 20:33 ` Casey Schaufler
2017-06-22 20:33 ` Casey Schaufler
2017-06-22 20:33 ` Casey Schaufler
[not found] ` <2bf08b3e-27f4-3592-d5e2-a823401ac644-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-22 21:03 ` Stefan Berger
2017-06-22 21:03 ` Stefan Berger
2017-06-22 21:03 ` Stefan Berger
2017-06-22 21:03 ` Stefan Berger
2017-06-22 21:09 ` Serge E. Hallyn
2017-06-22 21:09 ` Serge E. Hallyn
2017-06-22 21:09 ` Serge E. Hallyn
[not found] ` <20170622210925.GA32691-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-22 22:40 ` Casey Schaufler
2017-06-22 22:40 ` Casey Schaufler
2017-06-22 22:40 ` Casey Schaufler
2017-06-22 22:40 ` Casey Schaufler
[not found] ` <45e59e2e-0e00-cb9a-2f85-dc4606338a08-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-22 23:07 ` Serge E. Hallyn
2017-06-22 23:07 ` Serge E. Hallyn
2017-06-22 23:07 ` Serge E. Hallyn
[not found] ` <70a09f1b-e82c-a25c-9325-d5d757b1b695-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-22 20:12 ` Stefan Berger
2017-06-22 23:29 ` James Bottomley
2017-06-22 23:29 ` James Bottomley
2017-06-22 23:29 ` James Bottomley
2017-06-22 23:32 ` Serge E. Hallyn
2017-06-22 23:32 ` Serge E. Hallyn
[not found] ` <1498174161.7636.4.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-06-22 23:32 ` Serge E. Hallyn
2017-06-22 23:36 ` Serge E. Hallyn
2017-06-22 23:36 ` Serge E. Hallyn
2017-06-22 23:36 ` Serge E. Hallyn
2017-06-23 0:13 ` James Bottomley
2017-06-23 0:13 ` James Bottomley
2017-06-23 0:13 ` James Bottomley
[not found] ` <1498176787.7636.11.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-06-23 1:19 ` Serge E. Hallyn
2017-06-23 17:37 ` Eric W. Biederman
2017-06-23 1:19 ` Serge E. Hallyn
2017-06-23 1:19 ` Serge E. Hallyn
2017-06-23 17:37 ` Eric W. Biederman
2017-06-23 17:37 ` Eric W. Biederman
2017-06-23 17:37 ` Eric W. Biederman
[not found] ` <87efuaip08.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-06-23 18:39 ` Serge E. Hallyn
2017-06-23 18:39 ` Serge E. Hallyn
2017-06-23 18:39 ` Serge E. Hallyn
[not found] ` <20170622233619.GC2894-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 0:13 ` James Bottomley
-- strict thread matches above, loose matches on Subject: below --
2017-06-22 18:59 Stefan Berger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ef37880d-6baa-12a6-eab1-bcd0a4e94d53@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=amir73il@gmail.com \
--cc=christian.brauner@mailbox.org \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lkp@01.org \
--cc=serge@hallyn.com \
--cc=stefanb@linux.vnet.ibm.com \
--cc=tycho@docker.com \
--cc=vgoyal@redhat.com \
--cc=xiaolong.ye@intel.com \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.