From: Mimi Zohar <zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
To: Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>
Cc: Mimi Zohar <zohar-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
James.Bottomley-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org,
linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"Eric W. Biederman"
<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org,
lkp-JC7UmRfGjtg@public.gmane.org
Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces
Date: Fri, 14 Jul 2017 15:43:46 -0400 [thread overview]
Message-ID: <1500061426.3583.65.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170714192909.zoxnlm32nrxguqao-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote:
> On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
> >
> > If I'm understanding the discussion correctly, this isn't an issue for
> > layered copy on write filesystems, as each fs layer could have it's
> > own set of xattrs. The underlying and layered xattrs should be able
> > to co-exist. Use the layered xattr if it exists, but fall back to
> > using the underlying xattr if it doesn't.
>
> Note that this assumes that it is possible to "copy up" the xattrs
> without necessarily "copying up" all of the data blocks. This might
> be true for some layers, but I don't believe it is currently true for
> overlayfs, for example.
Ok, so for the use case scneario where the container owner is willing
to use the public key distributed with the files, then only those
files that are new or modified in the overlay would need to be signed
with a key local to the overlay. In the worst case scenario, where
the container owner is only willing to trust their own public key, I
guess we can live with having to copy up the files.
Mimi
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
WARNING: multiple messages have this Message-ID (diff)
From: zohar@linux.vnet.ibm.com (Mimi Zohar)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v2] xattr: Enable security.capability in user namespaces
Date: Fri, 14 Jul 2017 15:43:46 -0400 [thread overview]
Message-ID: <1500061426.3583.65.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170714192909.zoxnlm32nrxguqao@thunk.org>
On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote:
> On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
> >
> > If I'm understanding the discussion correctly, this isn't an issue for
> > layered copy on write filesystems, as each fs layer could have it's
> > own set of xattrs. ?The underlying and layered xattrs should be able
> > to co-exist. ?Use the layered xattr if it exists, but fall back to
> > using the underlying xattr if it doesn't.
>
> Note that this assumes that it is possible to "copy up" the xattrs
> without necessarily "copying up" all of the data blocks. This might
> be true for some layers, but I don't believe it is currently true for
> overlayfs, for example.
Ok, so for the use case scneario where the container owner is willing
to use the public key distributed with the files, then only those
files that are new or modified in the overlay would need to be signed
with a key local to the overlay. ?In the worst case scenario, where
the container owner is only willing to trust their own public key, I
guess we can live with having to copy up the files.
Mimi
--
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: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: lkp@lists.01.org
Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces
Date: Fri, 14 Jul 2017 15:43:46 -0400 [thread overview]
Message-ID: <1500061426.3583.65.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170714192909.zoxnlm32nrxguqao@thunk.org>
[-- Attachment #1: Type: text/plain, Size: 1130 bytes --]
On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote:
> On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
> >
> > If I'm understanding the discussion correctly, this isn't an issue for
> > layered copy on write filesystems, as each fs layer could have it's
> > own set of xattrs. The underlying and layered xattrs should be able
> > to co-exist. Use the layered xattr if it exists, but fall back to
> > using the underlying xattr if it doesn't.
>
> Note that this assumes that it is possible to "copy up" the xattrs
> without necessarily "copying up" all of the data blocks. This might
> be true for some layers, but I don't believe it is currently true for
> overlayfs, for example.
Ok, so for the use case scneario where the container owner is willing
to use the public key distributed with the files, then only those
files that are new or modified in the overlay would need to be signed
with a key local to the overlay. In the worst case scenario, where
the container owner is only willing to trust their own public key, I
guess we can live with having to copy up the files.
Mimi
WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
Stefan Berger <stefanb@linux.vnet.ibm.com>,
Mimi Zohar <zohar@us.ibm.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
containers@lists.linux-foundation.org, lkp@01.org,
linux-kernel@vger.kernel.org, tycho@docker.com,
James.Bottomley@HansenPartnership.com, vgoyal@redhat.com,
christian.brauner@mailbox.org, amir73il@gmail.com,
linux-security-module@vger.kernel.org, casey@schaufler-ca.com
Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces
Date: Fri, 14 Jul 2017 15:43:46 -0400 [thread overview]
Message-ID: <1500061426.3583.65.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <20170714192909.zoxnlm32nrxguqao@thunk.org>
On Fri, 2017-07-14 at 15:29 -0400, Theodore Ts'o wrote:
> On Fri, Jul 14, 2017 at 02:48:10PM -0400, Mimi Zohar wrote:
> >
> > If I'm understanding the discussion correctly, this isn't an issue for
> > layered copy on write filesystems, as each fs layer could have it's
> > own set of xattrs. The underlying and layered xattrs should be able
> > to co-exist. Use the layered xattr if it exists, but fall back to
> > using the underlying xattr if it doesn't.
>
> Note that this assumes that it is possible to "copy up" the xattrs
> without necessarily "copying up" all of the data blocks. This might
> be true for some layers, but I don't believe it is currently true for
> overlayfs, for example.
Ok, so for the use case scneario where the container owner is willing
to use the public key distributed with the files, then only those
files that are new or modified in the overlay would need to be signed
with a key local to the overlay. In the worst case scenario, where
the container owner is only willing to trust their own public key, I
guess we can live with having to copy up the files.
Mimi
next prev parent reply other threads:[~2017-07-14 19:43 UTC|newest]
Thread overview: 288+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-11 15:05 [PATCH v2] Enable namespaced file capabilities Stefan Berger
2017-07-11 15:05 ` Stefan Berger
[not found] ` <1499785511-17192-1-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-11 15:05 ` [PATCH v2] xattr: Enable security.capability in user namespaces Stefan Berger
2017-07-11 15:05 ` Stefan Berger
2017-07-11 17:12 ` Serge E. Hallyn
2017-07-11 17:12 ` Serge E. Hallyn
[not found] ` <20170711171222.GB31603-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-07-12 0:15 ` Stefan Berger
2017-07-12 0:15 ` Stefan Berger
2017-07-12 0:15 ` Stefan Berger
2017-07-12 0:15 ` Stefan Berger
2017-07-12 0:47 ` Serge E. Hallyn
2017-07-12 0:47 ` Serge E. Hallyn
[not found] ` <ca6e0001-6aeb-74dc-ab91-44aed3b7d128-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-12 0:47 ` Serge E. Hallyn
2017-07-12 3:45 ` Serge E. Hallyn
2017-07-12 3:45 ` Serge E. Hallyn
[not found] ` <20170712034503.GA8270-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-07-12 11:35 ` Stefan Berger
2017-07-12 11:35 ` Stefan Berger
2017-07-12 11:35 ` Stefan Berger
2017-07-12 11:35 ` Stefan Berger
[not found] ` <8c3e8c6f-52c5-5b04-8cad-1aeae25f0ec6-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-12 17:32 ` Serge E. Hallyn
2017-07-12 17:32 ` Serge E. Hallyn
2017-07-12 17:32 ` Serge E. Hallyn
[not found] ` <1499785511-17192-2-git-send-email-stefanb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-11 17:12 ` Serge E. Hallyn
2017-07-12 3:45 ` Serge E. Hallyn
2017-07-12 7:59 ` James Morris
2017-07-12 13:25 ` Eric W. Biederman
2017-07-12 17:53 ` Vivek Goyal
2017-07-12 17:53 ` Vivek Goyal
2017-07-12 17:53 ` Vivek Goyal
2017-07-12 17:53 ` Vivek Goyal
[not found] ` <20170712175357.GA32609-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-12 19:19 ` Stefan Berger
2017-07-12 19:19 ` Stefan Berger
2017-07-12 19:19 ` Stefan Berger
2017-07-12 19:19 ` Stefan Berger
2017-07-14 23:41 ` Eric W. Biederman
2017-07-17 18:58 ` Vivek Goyal
2017-07-17 18:58 ` Vivek Goyal
2017-07-17 18:58 ` Vivek Goyal
2017-07-17 18:58 ` Vivek Goyal
[not found] ` <20170717185811.GC15794-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-17 20:50 ` Stefan Berger
2017-07-17 20:50 ` Stefan Berger
2017-07-17 20:50 ` Stefan Berger
2017-07-17 20:50 ` Stefan Berger
2017-07-18 11:48 ` Vivek Goyal
2017-07-18 11:48 ` Vivek Goyal
2017-07-18 11:48 ` Vivek Goyal
[not found] ` <20170718114849.GA8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-18 12:05 ` Stefan Berger
2017-07-18 12:05 ` Stefan Berger
2017-07-18 12:05 ` Stefan Berger
2017-07-18 12:05 ` Stefan Berger
2017-07-18 12:30 ` Vivek Goyal
2017-07-18 12:30 ` Vivek Goyal
2017-07-18 12:30 ` Vivek Goyal
2017-07-18 12:36 ` Vivek Goyal
2017-07-18 12:36 ` Vivek Goyal
2017-07-18 12:36 ` Vivek Goyal
2017-07-18 13:29 ` Eric W. Biederman
2017-07-18 13:29 ` Eric W. Biederman
2017-07-18 13:29 ` Eric W. Biederman
[not found] ` <20170718123603.GC8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-18 13:29 ` Eric W. Biederman
2017-07-18 13:21 ` Stefan Berger
2017-07-18 13:21 ` Stefan Berger
2017-07-18 13:21 ` Stefan Berger
[not found] ` <cc515ca0-c5fa-412f-3f57-a41178b060a9-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-18 14:57 ` Vivek Goyal
2017-07-18 14:57 ` Vivek Goyal
2017-07-18 14:57 ` Vivek Goyal
2017-07-18 14:57 ` Vivek Goyal
2017-07-18 16:11 ` Stefan Berger
2017-07-18 16:11 ` Stefan Berger
2017-07-18 16:11 ` Stefan Berger
[not found] ` <20170718145716.GA25494-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-18 16:11 ` Stefan Berger
[not found] ` <20170718123009.GB8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-18 12:36 ` Vivek Goyal
2017-07-18 13:21 ` Stefan Berger
[not found] ` <55971eea-fde2-439a-2fe5-d0ae5e80bc22-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-18 12:30 ` Vivek Goyal
[not found] ` <7a39e8a6-a33b-f6a8-3fd5-6211c075ab91-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-18 11:48 ` Vivek Goyal
2017-07-20 1:05 ` [lkp-robot] [xattr] 3f3bf5920d: ltp.userns06.fail kernel test robot
2017-07-20 1:05 ` kernel test robot
2017-07-20 1:05 ` [LTP] " kernel test robot
2017-07-12 7:59 ` [PATCH v2] xattr: Enable security.capability in user namespaces James Morris
2017-07-12 7:59 ` James Morris
2017-07-12 7:59 ` James Morris
2017-07-12 13:25 ` Eric W. Biederman
2017-07-12 13:25 ` Eric W. Biederman
2017-07-12 13:25 ` Eric W. Biederman
[not found] ` <87mv89iy7q.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-12 17:03 ` Serge E. Hallyn
2017-07-12 17:03 ` Serge E. Hallyn
2017-07-12 17:03 ` Serge E. Hallyn
[not found] ` <20170712170346.GA17974-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-07-12 22:20 ` James Morris
2017-07-12 22:20 ` James Morris
2017-07-12 22:20 ` James Morris
2017-07-12 22:20 ` James Morris
2017-07-13 0:33 ` Eric W. Biederman
2017-07-13 0:33 ` Eric W. Biederman
2017-07-13 0:33 ` Eric W. Biederman
[not found] ` <87o9spfa5v.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-13 1:01 ` Serge E. Hallyn
2017-07-13 1:01 ` Serge E. Hallyn
2017-07-13 1:01 ` Serge E. Hallyn
[not found] ` <alpine.LRH.2.20.1707130820050.16810-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
2017-07-13 0:33 ` Eric W. Biederman
2017-07-12 23:13 ` Eric W. Biederman
2017-07-12 23:13 ` Eric W. Biederman
2017-07-12 23:13 ` Eric W. Biederman
2017-07-12 23:13 ` Eric W. Biederman
2017-07-13 0:43 ` Serge E. Hallyn
2017-07-13 0:43 ` Serge E. Hallyn
[not found] ` <877ezdgsey.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-13 0:43 ` Serge E. Hallyn
2017-07-13 0:44 ` Stefan Berger
2017-07-13 0:44 ` Stefan Berger
2017-07-13 0:44 ` Stefan Berger
2017-07-13 0:44 ` Stefan Berger
[not found] ` <74664cc8-bc3e-75d6-5892-f8934404349f-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-13 1:15 ` Theodore Ts'o
2017-07-13 1:15 ` Theodore Ts'o
2017-07-13 1:15 ` Theodore Ts'o
2017-07-13 1:15 ` Theodore Ts'o
2017-07-13 12:11 ` Eric W. Biederman
2017-07-13 12:11 ` Eric W. Biederman
2017-07-13 12:11 ` Eric W. Biederman
[not found] ` <87y3rscz9j.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-13 16:40 ` Theodore Ts'o
2017-07-13 16:40 ` Theodore Ts'o
2017-07-13 16:40 ` Theodore Ts'o
2017-07-13 16:40 ` Theodore Ts'o
2017-07-13 17:05 ` Stefan Berger
2017-07-13 17:05 ` Stefan Berger
2017-07-13 17:05 ` Stefan Berger
2017-07-13 17:39 ` Eric W. Biederman
2017-07-13 17:39 ` Eric W. Biederman
2017-07-13 17:39 ` Eric W. Biederman
[not found] ` <8760ew9qyp.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-13 19:14 ` Theodore Ts'o
2017-07-13 19:14 ` Theodore Ts'o
2017-07-13 19:14 ` Theodore Ts'o
2017-07-13 19:14 ` Theodore Ts'o
2017-07-13 19:41 ` Serge E. Hallyn
2017-07-13 19:41 ` Serge E. Hallyn
[not found] ` <20170713191429.vfaetqscxd7hniwq-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-07-13 19:41 ` Serge E. Hallyn
2017-07-13 21:17 ` Serge E. Hallyn
2017-07-13 21:17 ` Serge E. Hallyn
2017-07-13 21:17 ` Serge E. Hallyn
[not found] ` <29fdda5e-ed4a-bcda-e3cc-c06ab87973ce-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-13 17:39 ` Eric W. Biederman
2017-07-18 7:01 ` James Morris
2017-07-18 7:01 ` James Morris
2017-07-18 7:01 ` James Morris
2017-07-18 7:01 ` James Morris
2017-07-18 12:12 ` Stefan Berger
2017-07-18 12:12 ` Stefan Berger
2017-07-18 12:12 ` Stefan Berger
[not found] ` <aae67245-4c9c-f79e-b821-40753e732f65-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-18 13:26 ` Eric W. Biederman
2017-07-18 13:26 ` Eric W. Biederman
2017-07-18 13:26 ` Eric W. Biederman
2017-07-18 13:26 ` Eric W. Biederman
2017-07-18 23:13 ` Serge E. Hallyn
2017-07-18 23:13 ` Serge E. Hallyn
[not found] ` <871spdj2pe.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-18 23:13 ` Serge E. Hallyn
[not found] ` <alpine.LRH.2.20.1707181659030.5209-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
2017-07-18 12:12 ` Stefan Berger
2017-07-13 17:14 ` Eric W. Biederman
2017-07-13 17:14 ` Eric W. Biederman
2017-07-13 17:14 ` Eric W. Biederman
2017-07-13 17:33 ` Stefan Berger
2017-07-13 17:33 ` Stefan Berger
2017-07-13 17:33 ` Stefan Berger
[not found] ` <847ccb2a-30c0-a94c-df6f-091c8901eaa0-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-13 17:49 ` Eric W. Biederman
2017-07-13 17:49 ` Eric W. Biederman
2017-07-13 17:49 ` Eric W. Biederman
2017-07-13 17:49 ` Eric W. Biederman
2017-07-13 19:48 ` Serge E. Hallyn
2017-07-13 19:48 ` Serge E. Hallyn
[not found] ` <20170713194842.GB4895-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-07-13 21:12 ` Eric W. Biederman
2017-07-13 21:12 ` Eric W. Biederman
2017-07-13 21:12 ` Eric W. Biederman
2017-07-13 21:12 ` Eric W. Biederman
[not found] ` <87bmoo8bxb.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-13 19:48 ` Serge E. Hallyn
2017-07-13 21:35 ` Stefan Berger
2017-07-13 21:35 ` Stefan Berger
[not found] ` <9a3010e5-ca2b-5e7a-656b-fcc14f7bec4e-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-14 0:38 ` Eric W. Biederman
2017-07-14 0:38 ` Eric W. Biederman
2017-07-14 0:38 ` Eric W. Biederman
2017-07-14 0:38 ` Eric W. Biederman
[not found] ` <87h8yf7szd.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-14 11:32 ` Stefan Berger
2017-07-14 11:32 ` Stefan Berger
2017-07-14 11:32 ` Stefan Berger
2017-07-14 11:32 ` Stefan Berger
[not found] ` <65dbe654-0d99-03fa-c838-5a726b462826-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-14 12:04 ` Eric W. Biederman
2017-07-14 12:04 ` Eric W. Biederman
2017-07-14 12:04 ` Eric W. Biederman
2017-07-14 12:04 ` Eric W. Biederman
[not found] ` <87vamv2pj0.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-14 12:39 ` Stefan Berger
2017-07-14 12:39 ` Stefan Berger
2017-07-14 12:39 ` Stefan Berger
2017-07-14 12:39 ` Stefan Berger
2017-07-14 13:34 ` Serge E. Hallyn
2017-07-14 13:34 ` Serge E. Hallyn
2017-07-14 13:34 ` Serge E. Hallyn
2017-07-14 15:22 ` Stefan Berger
2017-07-14 15:22 ` Stefan Berger
2017-07-14 15:22 ` Stefan Berger
2017-07-14 17:35 ` Serge E. Hallyn
2017-07-14 17:35 ` Serge E. Hallyn
2017-07-14 18:17 ` Eric W. Biederman
2017-07-14 18:17 ` Eric W. Biederman
2017-07-14 18:17 ` Eric W. Biederman
2017-07-14 18:48 ` Mimi Zohar
2017-07-14 18:48 ` Mimi Zohar
2017-07-14 18:48 ` Mimi Zohar
2017-07-14 18:52 ` James Bottomley
2017-07-14 18:52 ` James Bottomley
2017-07-14 18:52 ` James Bottomley
[not found] ` <1500058362.2853.28.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-07-14 20:03 ` Mimi Zohar
2017-07-14 20:03 ` Mimi Zohar
2017-07-14 20:03 ` Mimi Zohar
2017-07-14 20:03 ` Mimi Zohar
[not found] ` <1500062619.3583.71.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-14 20:39 ` James Bottomley
2017-07-14 20:39 ` James Bottomley
2017-07-14 20:39 ` James Bottomley
2017-07-14 20:39 ` James Bottomley
2017-07-14 21:34 ` Theodore Ts'o
2017-07-14 21:34 ` Theodore Ts'o
2017-07-14 21:34 ` Theodore Ts'o
[not found] ` <20170714213449.gtxtkqtxifk5j4wp-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-07-14 23:22 ` Eric W. Biederman
2017-07-14 23:22 ` Eric W. Biederman
2017-07-14 23:22 ` Eric W. Biederman
2017-07-14 23:22 ` Eric W. Biederman
2017-07-14 23:29 ` Mimi Zohar
2017-07-14 23:29 ` Mimi Zohar
2017-07-14 23:29 ` Mimi Zohar
2017-07-14 23:53 ` Eric W. Biederman
2017-07-14 23:53 ` Eric W. Biederman
2017-07-14 23:53 ` Eric W. Biederman
[not found] ` <1500064799.2853.36.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2017-07-14 21:34 ` Theodore Ts'o
2017-07-14 23:29 ` Mimi Zohar
2017-07-14 23:53 ` Eric W. Biederman
[not found] ` <1500058090.3583.28.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-14 18:52 ` James Bottomley
2017-07-14 19:29 ` Theodore Ts'o
2017-07-14 19:29 ` Theodore Ts'o
2017-07-14 19:29 ` Theodore Ts'o
2017-07-14 19:29 ` Theodore Ts'o
[not found] ` <20170714192909.zoxnlm32nrxguqao-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-07-14 19:43 ` Mimi Zohar [this message]
2017-07-14 19:43 ` Mimi Zohar
2017-07-14 19:43 ` Mimi Zohar
2017-07-14 19:43 ` Mimi Zohar
[not found] ` <20170714173556.GA19669-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-07-14 18:17 ` Eric W. Biederman
2017-07-14 18:48 ` Mimi Zohar
[not found] ` <xagsmtp2.20170714182525.6604@vmsdvm4.vnet.ibm.com>
2017-07-14 19:26 ` Mimi Zohar
2017-07-14 19:26 ` Mimi Zohar
2017-07-14 19:26 ` Mimi Zohar
[not found] ` <1500060374.3583.57.camel-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-15 0:02 ` Eric W. Biederman
2017-07-26 3:00 ` Serge E. Hallyn
2017-07-26 3:00 ` Serge E. Hallyn
2017-07-26 3:00 ` Serge E. Hallyn
2017-07-26 13:57 ` Mimi Zohar
2017-07-26 13:57 ` Mimi Zohar
2017-07-26 13:57 ` Mimi Zohar
[not found] ` <20170726030007.GA10087-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-07-26 13:57 ` Mimi Zohar
2017-07-15 0:02 ` Eric W. Biederman
2017-07-15 0:02 ` Eric W. Biederman
2017-07-15 0:02 ` Eric W. Biederman
[not found] ` <xagsmtp3.20170715001054.9173@uk1vsc.vnet.ibm.com>
[not found] ` <xagsmtp3.20170715001054.9173-17CmTKLGOXFpnrxNGchxj0EOCMrvLtNR@public.gmane.org>
2017-07-16 11:25 ` Mimi Zohar
2017-07-16 11:25 ` Mimi Zohar
2017-07-16 11:25 ` Mimi Zohar
2017-07-16 11:25 ` Mimi Zohar
[not found] ` <xagsmtp2.20170714182525.6604-SsZeXQfhYdoOFdY8m0e24VaTQe2KTcn/@public.gmane.org>
2017-07-14 19:26 ` Mimi Zohar
[not found] ` <596f808b-e21d-8296-5fef-23c1ce7ab778-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-14 17:35 ` Serge E. Hallyn
2017-07-14 17:36 ` Eric W. Biederman
2017-07-14 17:36 ` Eric W. Biederman
2017-07-14 17:36 ` Eric W. Biederman
2017-07-14 17:36 ` Eric W. Biederman
[not found] ` <87pod22a4x.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-14 19:22 ` Stefan Berger
2017-07-14 19:22 ` Stefan Berger
2017-07-14 19:22 ` Stefan Berger
2017-07-14 19:22 ` Stefan Berger
[not found] ` <20170714133437.GA16737-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-07-14 15:22 ` Stefan Berger
2017-07-13 21:21 ` Serge E. Hallyn
2017-07-13 21:21 ` Serge E. Hallyn
2017-07-13 21:21 ` Serge E. Hallyn
[not found] ` <87k23cb6os.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-13 17:33 ` Stefan Berger
[not found] ` <20170713164012.brj2flnkaaks2oci-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-07-13 17:05 ` Stefan Berger
2017-07-13 17:14 ` Eric W. Biederman
2017-07-13 21:13 ` Serge E. Hallyn
2017-07-13 21:13 ` Serge E. Hallyn
2017-07-13 21:13 ` Serge E. Hallyn
[not found] ` <20170713011554.xwmrgkzfwnibvgcu-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-07-13 2:34 ` Serge E. Hallyn
2017-07-13 2:34 ` Serge E. Hallyn
2017-07-13 2:34 ` Serge E. Hallyn
2017-07-13 12:11 ` Eric W. Biederman
2017-07-14 23:41 ` Eric W. Biederman
2017-07-14 23:41 ` Eric W. Biederman
2017-07-14 23:41 ` Eric W. Biederman
2017-07-15 21:27 ` Stefan Berger
2017-07-15 21:27 ` Stefan Berger
2017-07-15 21:27 ` Stefan Berger
[not found] ` <87d192si18.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-15 21:27 ` 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=1500061426.3583.65.camel@linux.vnet.ibm.com \
--to=zohar-23vcf4htsmix0ybbhkvfkdbpr1lh4cv8@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=tytso-3s7WtUTddSA@public.gmane.org \
--cc=zohar-r/Jw6+rmf7HQT0dZR+AlfA@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.