From: "Serge E. Hallyn" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org>
To: Casey Schaufler <casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
Cc: zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
xiaolong.ye-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org,
linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org,
lkp-JC7UmRfGjtg@public.gmane.org
Subject: Re: [PATCH 0/3] Enable namespaced file capabilities
Date: Thu, 22 Jun 2017 16:09:25 -0500 [thread overview]
Message-ID: <20170622210925.GA32691@mail.hallyn.com> (raw)
In-Reply-To: <2bf08b3e-27f4-3592-d5e2-a823401ac644-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
Quoting Casey Schaufler (casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org):
> On 6/22/2017 1:12 PM, Stefan Berger wrote:
> > On 06/22/2017 03:59 PM, Casey Schaufler wrote:
> >> On 6/22/2017 11:59 AM, Stefan Berger 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.
> >> You need to identify the instance of the user namespace for
> >> this to work right on a system with multiple user namespaces.
> >> If I have a shared filesystem mounted in two different user
> >> namespaces a change by one will affect the other.
> >
> > Two different user namespaces with different uid mappings will not affect each other.
>
> But two namespaces with the same uid mapping will, and I
> don't think this meets the principle of least astonishment.
It does. If you have one filesystem shared among multiple
containers, then it needs to be either read-only, or you
need to know what you're doing.
> I also object to associating capabilities with UIDs. The
> whole point of capabilities is to disassociate UID 0 from
> privilege. What you've done is explicitly associate a UID
> with the ability to have privilege. That's an architectural
> regression.
IMO this is looking at it the wrong way. From inside the container's
viewpoint, the capabilities are not associated with a uid. Any
task, regardles off uid, in the container, which executes the file,
gets the privilege. IMO that satisfies the intent of file capabilities.
-serge
WARNING: multiple messages have this Message-ID (diff)
From: serge@hallyn.com (Serge E. Hallyn)
To: linux-security-module@vger.kernel.org
Subject: [PATCH 0/3] Enable namespaced file capabilities
Date: Thu, 22 Jun 2017 16:09:25 -0500 [thread overview]
Message-ID: <20170622210925.GA32691@mail.hallyn.com> (raw)
In-Reply-To: <2bf08b3e-27f4-3592-d5e2-a823401ac644@schaufler-ca.com>
Quoting Casey Schaufler (casey at schaufler-ca.com):
> On 6/22/2017 1:12 PM, Stefan Berger wrote:
> > On 06/22/2017 03:59 PM, Casey Schaufler wrote:
> >> On 6/22/2017 11:59 AM, Stefan Berger 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.
> >> You need to identify the instance of the user namespace for
> >> this to work right on a system with multiple user namespaces.
> >> If I have a shared filesystem mounted in two different user
> >> namespaces a change by one will affect the other.
> >
> > Two different user namespaces with different uid mappings will not affect each other.
>
> But two namespaces with the same uid mapping will, and I
> don't think this meets the principle of least astonishment.
It does. If you have one filesystem shared among multiple
containers, then it needs to be either read-only, or you
need to know what you're doing.
> I also object to associating capabilities with UIDs. The
> whole point of capabilities is to disassociate UID 0 from
> privilege. What you've done is explicitly associate a UID
> with the ability to have privilege. That's an architectural
> regression.
IMO this is looking at it the wrong way. From inside the container's
viewpoint, the capabilities are not associated with a uid. Any
task, regardles off uid, in the container, which executes the file,
gets the privilege. IMO that satisfies the intent of file capabilities.
-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: "Serge E. Hallyn" <serge@hallyn.com>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>,
ebiederm@xmission.com, containers@lists.linux-foundation.org,
lkp@01.org, xiaolong.ye@intel.com, linux-kernel@vger.kernel.org,
zohar@linux.vnet.ibm.com, serge@hallyn.com, tycho@docker.com,
James.Bottomley@HansenPartnership.com,
christian.brauner@mailbox.org, vgoyal@redhat.com,
amir73il@gmail.com, linux-security-module@vger.kernel.org
Subject: Re: [PATCH 0/3] Enable namespaced file capabilities
Date: Thu, 22 Jun 2017 16:09:25 -0500 [thread overview]
Message-ID: <20170622210925.GA32691@mail.hallyn.com> (raw)
In-Reply-To: <2bf08b3e-27f4-3592-d5e2-a823401ac644@schaufler-ca.com>
Quoting Casey Schaufler (casey@schaufler-ca.com):
> On 6/22/2017 1:12 PM, Stefan Berger wrote:
> > On 06/22/2017 03:59 PM, Casey Schaufler wrote:
> >> On 6/22/2017 11:59 AM, Stefan Berger 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.
> >> You need to identify the instance of the user namespace for
> >> this to work right on a system with multiple user namespaces.
> >> If I have a shared filesystem mounted in two different user
> >> namespaces a change by one will affect the other.
> >
> > Two different user namespaces with different uid mappings will not affect each other.
>
> But two namespaces with the same uid mapping will, and I
> don't think this meets the principle of least astonishment.
It does. If you have one filesystem shared among multiple
containers, then it needs to be either read-only, or you
need to know what you're doing.
> I also object to associating capabilities with UIDs. The
> whole point of capabilities is to disassociate UID 0 from
> privilege. What you've done is explicitly associate a UID
> with the ability to have privilege. That's an architectural
> regression.
IMO this is looking at it the wrong way. From inside the container's
viewpoint, the capabilities are not associated with a uid. Any
task, regardles off uid, in the container, which executes the file,
gets the privilege. IMO that satisfies the intent of file capabilities.
-serge
next prev parent reply other threads:[~2017-06-22 21:09 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
[not found] ` <1498157989-11814-2-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-24 21:02 ` 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
2017-06-24 21:02 ` 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 ` kbuild test robot
2017-06-24 21:02 ` kbuild test robot
2017-06-22 18:59 ` [PATCH 3/3] Enable security.selinux " 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
[not found] ` <70a09f1b-e82c-a25c-9325-d5d757b1b695-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-22 20:12 ` Stefan Berger
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 [this message]
2017-06-22 21:09 ` Serge E. Hallyn
2017-06-22 21:09 ` Serge E. Hallyn
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] ` <20170622210925.GA32691-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-22 22:40 ` Casey Schaufler
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
2017-06-23 1:19 ` Serge E. Hallyn
2017-06-23 1:19 ` Serge E. Hallyn
[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 17:37 ` Eric W. Biederman
2017-06-23 17:37 ` Eric W. Biederman
2017-06-23 17:37 ` Eric W. Biederman
2017-06-23 18:39 ` Serge E. Hallyn
2017-06-23 18:39 ` Serge E. Hallyn
[not found] ` <87efuaip08.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-06-23 18:39 ` Serge E. Hallyn
[not found] ` <20170622233619.GC2894-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 0:13 ` James Bottomley
[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
[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
2017-06-23 16:30 ` Serge E. Hallyn
2017-06-23 16:30 ` Serge E. Hallyn
2017-06-23 16:53 ` Casey Schaufler
2017-06-23 16:53 ` Casey Schaufler
2017-06-23 16:53 ` Casey Schaufler
[not found] ` <ef37880d-6baa-12a6-eab1-bcd0a4e94d53-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org>
2017-06-23 17:01 ` Serge E. Hallyn
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
2017-06-23 18:32 ` Serge E. Hallyn
2017-06-23 18:32 ` Serge E. Hallyn
[not found] ` <8760fmh9vc.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
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] ` <20170623163030.GA18820-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 16:53 ` Casey Schaufler
2017-06-23 17:07 ` James Bottomley
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
2017-06-23 18:34 ` Serge E. Hallyn
2017-06-23 18:34 ` Serge E. Hallyn
[not found] ` <d288ea69-adec-f257-30cb-b1d9c57c996b-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-23 18:34 ` Serge E. Hallyn
2017-06-23 18:08 ` Stefan Berger
2017-06-23 18:08 ` Stefan Berger
2017-06-23 18:08 ` Stefan Berger
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
[not found] ` <3404c486-c848-3283-50f7-2283cb631e8e-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-06-23 18:35 ` Serge E. Hallyn
[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:00 ` Serge E. Hallyn
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
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
[not found] ` <20170623203643.GC24779-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-06-23 20:51 ` Serge E. Hallyn
2017-06-23 20:51 ` Serge E. Hallyn
2017-06-23 20:51 ` Serge E. Hallyn
[not found] ` <20170623201723.GA22857-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-06-23 20:36 ` Vivek Goyal
[not found] ` <20170623200956.GB24779-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-06-23 20:17 ` Serge E. Hallyn
-- 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=20170622210925.GA32691@mail.hallyn.com \
--to=serge-a9i7lubdfnhqt0dzr+alfa@public.gmane.org \
--cc=James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org \
--cc=casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lkp-JC7UmRfGjtg@public.gmane.org \
--cc=xiaolong.ye-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
/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.