From: Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>
To: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Cc: lkp-JC7UmRfGjtg@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,
casey-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org,
zohar-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org
Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces
Date: Thu, 13 Jul 2017 15:14:29 -0400 [thread overview]
Message-ID: <20170713191429.vfaetqscxd7hniwq@thunk.org> (raw)
In-Reply-To: <8760ew9qyp.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > Can you define what 'scalable' means for you in this context?
> > From what I can see sharing a filesystem between multiple containers
> > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > size limitations of xattrs per file.
>
> Worse than that I believe you will find that filesystems are built on
> the assumption that there will be a small number of xattrs per file.
> So even if the vfs limitations were lifted the filesystem performance
> would suffer.
That's why I've been pushing here. If people try to do
security.capable@uid=1000
security.capable@uid=2000
security.capable@uid=3000
security.capable@uid=4000
security.capable@uid=5000
security.capable@uid=6000
security.capable@uid=7000
security.capable@uid=8000
security.capable@uid=9000
.
.
.
... where the values of all of these will be the same, this is going
to be *awful* even if the file system can support it.
So maybe we are better off if we define an xattr
security.capable@guest-container
... so the property is that it is ignored by the host ("real")
container, and in all of the subcontainers, it will be used if the
local container root is trying to execute the file.
Now, this doesn't support the solution of the "turtles all the way
down" insane containers configuraiton.
E.g., where in one container we boot a RHEL distro, which then
launches another container running another RHEL distro, and repeat
this 1000 times, for a very deeply nested subsubsubsubsub...container.
I think this is insane and we shouldn't support this, but I know there
are people who think this is a perfectly sane thing to do.
The other thing this doesn't support is someone who wants to use IMA,
and where the every single IMA is using a different signed HMAC:
security.ima@uid=1000
security.ima@uid=2000
security.ima@uid=3000
security.ima@uid=4000
security.ima@uid=5000
security.ima@uid=6000
security.ima@uid=7000
security.ima@uid=8000
security.ima@uid=9000
.
.
.
Where each security IMA could either be a 32 byte HMAC, or worse, a
256 byte RSA signed signature. Now let's assume there are 10,000
containers, each of which needs a separate RSA signature. This sounds
insane.... but I've seen things that I've thought were more insane
coming out of containerland, so it would be nice if we can get
something signed in blood promisng that no, we would *never* do
something that insane, or better yet, make it impossible to do from an
architectural standpoint.
- Ted
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>,
"Serge E. Hallyn" <serge@hallyn.com>,
containers@lists.linux-foundation.org, lkp@01.org,
linux-kernel@vger.kernel.org, zohar@linux.vnet.ibm.com,
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: Thu, 13 Jul 2017 15:14:29 -0400 [thread overview]
Message-ID: <20170713191429.vfaetqscxd7hniwq@thunk.org> (raw)
In-Reply-To: <8760ew9qyp.fsf@xmission.com>
On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > Can you define what 'scalable' means for you in this context?
> > From what I can see sharing a filesystem between multiple containers
> > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > size limitations of xattrs per file.
>
> Worse than that I believe you will find that filesystems are built on
> the assumption that there will be a small number of xattrs per file.
> So even if the vfs limitations were lifted the filesystem performance
> would suffer.
That's why I've been pushing here. If people try to do
security.capable@uid=1000
security.capable@uid=2000
security.capable@uid=3000
security.capable@uid=4000
security.capable@uid=5000
security.capable@uid=6000
security.capable@uid=7000
security.capable@uid=8000
security.capable@uid=9000
.
.
.
... where the values of all of these will be the same, this is going
to be *awful* even if the file system can support it.
So maybe we are better off if we define an xattr
security.capable@guest-container
... so the property is that it is ignored by the host ("real")
container, and in all of the subcontainers, it will be used if the
local container root is trying to execute the file.
Now, this doesn't support the solution of the "turtles all the way
down" insane containers configuraiton.
E.g., where in one container we boot a RHEL distro, which then
launches another container running another RHEL distro, and repeat
this 1000 times, for a very deeply nested subsubsubsubsub...container.
I think this is insane and we shouldn't support this, but I know there
are people who think this is a perfectly sane thing to do.
The other thing this doesn't support is someone who wants to use IMA,
and where the every single IMA is using a different signed HMAC:
security.ima@uid=1000
security.ima@uid=2000
security.ima@uid=3000
security.ima@uid=4000
security.ima@uid=5000
security.ima@uid=6000
security.ima@uid=7000
security.ima@uid=8000
security.ima@uid=9000
.
.
.
Where each security IMA could either be a 32 byte HMAC, or worse, a
256 byte RSA signed signature. Now let's assume there are 10,000
containers, each of which needs a separate RSA signature. This sounds
insane.... but I've seen things that I've thought were more insane
coming out of containerland, so it would be nice if we can get
something signed in blood promisng that no, we would *never* do
something that insane, or better yet, make it impossible to do from an
architectural standpoint.
- Ted
WARNING: multiple messages have this Message-ID (diff)
From: tytso@mit.edu (Theodore Ts'o)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v2] xattr: Enable security.capability in user namespaces
Date: Thu, 13 Jul 2017 15:14:29 -0400 [thread overview]
Message-ID: <20170713191429.vfaetqscxd7hniwq@thunk.org> (raw)
In-Reply-To: <8760ew9qyp.fsf@xmission.com>
On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > Can you define what 'scalable' means for you in this context?
> > From what I can see sharing a filesystem between multiple containers
> > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > size limitations of xattrs per file.
>
> Worse than that I believe you will find that filesystems are built on
> the assumption that there will be a small number of xattrs per file.
> So even if the vfs limitations were lifted the filesystem performance
> would suffer.
That's why I've been pushing here. If people try to do
security.capable at uid=1000
security.capable at uid=2000
security.capable at uid=3000
security.capable at uid=4000
security.capable at uid=5000
security.capable at uid=6000
security.capable at uid=7000
security.capable at uid=8000
security.capable at uid=9000
.
.
.
... where the values of all of these will be the same, this is going
to be *awful* even if the file system can support it.
So maybe we are better off if we define an xattr
security.capable at guest-container
... so the property is that it is ignored by the host ("real")
container, and in all of the subcontainers, it will be used if the
local container root is trying to execute the file.
Now, this doesn't support the solution of the "turtles all the way
down" insane containers configuraiton.
E.g., where in one container we boot a RHEL distro, which then
launches another container running another RHEL distro, and repeat
this 1000 times, for a very deeply nested subsubsubsubsub...container.
I think this is insane and we shouldn't support this, but I know there
are people who think this is a perfectly sane thing to do.
The other thing this doesn't support is someone who wants to use IMA,
and where the every single IMA is using a different signed HMAC:
security.ima at uid=1000
security.ima at uid=2000
security.ima at uid=3000
security.ima at uid=4000
security.ima at uid=5000
security.ima at uid=6000
security.ima at uid=7000
security.ima at uid=8000
security.ima at uid=9000
.
.
.
Where each security IMA could either be a 32 byte HMAC, or worse, a
256 byte RSA signed signature. Now let's assume there are 10,000
containers, each of which needs a separate RSA signature. This sounds
insane.... but I've seen things that I've thought were more insane
coming out of containerland, so it would be nice if we can get
something signed in blood promisng that no, we would *never* do
something that insane, or better yet, make it impossible to do from an
architectural standpoint.
- Ted
--
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: Theodore Ts'o <tytso@mit.edu>
To: lkp@lists.01.org
Subject: Re: [PATCH v2] xattr: Enable security.capability in user namespaces
Date: Thu, 13 Jul 2017 15:14:29 -0400 [thread overview]
Message-ID: <20170713191429.vfaetqscxd7hniwq@thunk.org> (raw)
In-Reply-To: <8760ew9qyp.fsf@xmission.com>
[-- Attachment #1: Type: text/plain, Size: 2720 bytes --]
On Thu, Jul 13, 2017 at 12:39:10PM -0500, Eric W. Biederman wrote:
> > Can you define what 'scalable' means for you in this context?
> > From what I can see sharing a filesystem between multiple containers
> > doesn't 'scale well' for virtualizing the xattrs primarily because of
> > size limitations of xattrs per file.
>
> Worse than that I believe you will find that filesystems are built on
> the assumption that there will be a small number of xattrs per file.
> So even if the vfs limitations were lifted the filesystem performance
> would suffer.
That's why I've been pushing here. If people try to do
security.capable(a)uid=1000
security.capable(a)uid=2000
security.capable(a)uid=3000
security.capable(a)uid=4000
security.capable(a)uid=5000
security.capable(a)uid=6000
security.capable(a)uid=7000
security.capable(a)uid=8000
security.capable(a)uid=9000
.
.
.
... where the values of all of these will be the same, this is going
to be *awful* even if the file system can support it.
So maybe we are better off if we define an xattr
security.capable(a)guest-container
... so the property is that it is ignored by the host ("real")
container, and in all of the subcontainers, it will be used if the
local container root is trying to execute the file.
Now, this doesn't support the solution of the "turtles all the way
down" insane containers configuraiton.
E.g., where in one container we boot a RHEL distro, which then
launches another container running another RHEL distro, and repeat
this 1000 times, for a very deeply nested subsubsubsubsub...container.
I think this is insane and we shouldn't support this, but I know there
are people who think this is a perfectly sane thing to do.
The other thing this doesn't support is someone who wants to use IMA,
and where the every single IMA is using a different signed HMAC:
security.ima(a)uid=1000
security.ima(a)uid=2000
security.ima(a)uid=3000
security.ima(a)uid=4000
security.ima(a)uid=5000
security.ima(a)uid=6000
security.ima(a)uid=7000
security.ima(a)uid=8000
security.ima(a)uid=9000
.
.
.
Where each security IMA could either be a 32 byte HMAC, or worse, a
256 byte RSA signed signature. Now let's assume there are 10,000
containers, each of which needs a separate RSA signature. This sounds
insane.... but I've seen things that I've thought were more insane
coming out of containerland, so it would be nice if we can get
something signed in blood promisng that no, we would *never* do
something that insane, or better yet, make it impossible to do from an
architectural standpoint.
- Ted
next prev parent reply other threads:[~2017-07-13 19:14 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
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
[not found] ` <20170711171222.GB31603-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2017-07-12 0:15 ` Stefan Berger
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
2017-07-12 7:59 ` 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
[not found] ` <alpine.LRH.2.20.1707130820050.16810-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
2017-07-13 0:33 ` Eric W. Biederman
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
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
[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-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 [this message]
2017-07-13 19:14 ` Theodore Ts'o
2017-07-13 19:14 ` Theodore Ts'o
2017-07-13 19:14 ` Theodore Ts'o
[not found] ` <20170713191429.vfaetqscxd7hniwq-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
2017-07-13 19:41 ` Serge E. Hallyn
2017-07-13 19:41 ` Serge E. Hallyn
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
[not found] ` <alpine.LRH.2.20.1707181659030.5209-gx6/JNMH7DfYtjvyW6yDsg@public.gmane.org>
2017-07-18 12:12 ` Stefan Berger
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
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
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] ` <20170713194842.GB4895-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
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
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
[not found] ` <20170714173556.GA19669-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
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: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
2017-07-14 23:22 ` Eric W. Biederman
2017-07-14 23:22 ` Eric W. Biederman
2017-07-14 23:22 ` Eric W. Biederman
[not found] ` <20170714213449.gtxtkqtxifk5j4wp-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
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
2017-07-14 19:43 ` Mimi Zohar
2017-07-14 19:43 ` Mimi Zohar
2017-07-14 19:43 ` Mimi Zohar
[not found] ` <xagsmtp2.20170714182525.6604@vmsdvm4.vnet.ibm.com>
[not found] ` <xagsmtp2.20170714182525.6604-SsZeXQfhYdoOFdY8m0e24VaTQe2KTcn/@public.gmane.org>
2017-07-14 19:26 ` Mimi Zohar
2017-07-14 19:26 ` Mimi Zohar
2017-07-14 19:26 ` Mimi Zohar
2017-07-14 19:26 ` 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] ` <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
[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] ` <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
[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-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] ` <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
2017-07-12 19:19 ` Stefan Berger
2017-07-12 19:19 ` Stefan Berger
2017-07-12 19:19 ` Stefan Berger
[not found] ` <20170712175357.GA32609-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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
[not found] ` <7a39e8a6-a33b-f6a8-3fd5-6211c075ab91-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2017-07-18 11:48 ` Vivek Goyal
2017-07-18 11:48 ` Vivek Goyal
2017-07-18 11:48 ` Vivek Goyal
2017-07-18 11:48 ` Vivek Goyal
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
[not found] ` <20170718123603.GC8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-18 13:29 ` Eric W. Biederman
2017-07-18 13:29 ` Eric W. Biederman
2017-07-18 13:29 ` Eric W. Biederman
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
[not found] ` <20170718145716.GA25494-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-18 16:11 ` Stefan Berger
2017-07-18 16:11 ` Stefan Berger
2017-07-18 16:11 ` Stefan Berger
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] ` <20170718114849.GA8233-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-07-18 12:05 ` Stefan Berger
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-14 23:41 ` [PATCH v2] xattr: Enable security.capability in user namespaces Eric W. Biederman
2017-07-14 23:41 ` Eric W. Biederman
2017-07-14 23:41 ` Eric W. Biederman
[not found] ` <87d192si18.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-15 21:27 ` Stefan Berger
2017-07-15 21:27 ` Stefan Berger
2017-07-15 21:27 ` Stefan Berger
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=20170713191429.vfaetqscxd7hniwq@thunk.org \
--to=tytso-3s7wtutddsa@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=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.