All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <20170623011924.GA4560@mail.hallyn.com>

diff --git a/a/1.txt b/N1/1.txt
index dfdf122..69ee658 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,4 +1,4 @@
-Quoting James Bottomley (James.Bottomley at HansenPartnership.com):
+Quoting James Bottomley (James.Bottomley@HansenPartnership.com):
 > On Thu, 2017-06-22 at 18:36 -0500, Serge E. Hallyn wrote:
 > > Yes, the use case is: to allow root in the container to set the
 > > privilege itself, without endangering any resources not owned by
@@ -26,7 +26,7 @@ can write a xattr targeted at their own root userid.
 > to subsets of these.
 
 Hm. In that case they should not be allowed to write your proposed
-'security.capability at uid' capability, because that would also grant
+'security.capability@uid' capability, because that would also grant
 capabilities over subuids which they were not delegated.
 
 (but see below)
@@ -44,13 +44,9 @@ capabilities over subuids which they were not delegated.
 > can't see we'd be mixing use cases in a physical system.
 
 I might be confused.  But thought CAP_SETFCAP against init_user_ns would
-be required to set 'security.capability at uid'.  That, or you could create
+be required to set 'security.capability@uid'.  That, or you could create
 a user namespace mapping [ 1 - 4294967295 ] to [ 0 = 4294967294 ], and
 have CAP_SETFCAP against that namespace.  Which would allow you to run
 without host root privilege.
 
 -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
diff --git a/a/content_digest b/N1/content_digest
index 490ff6d..186b790 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,13 +2,21 @@
  "ref\01498174161.7636.4.camel@HansenPartnership.com\0"
  "ref\020170622233619.GC2894@mail.hallyn.com\0"
  "ref\01498176787.7636.11.camel@HansenPartnership.com\0"
- "From\0serge@hallyn.com (Serge E. Hallyn)\0"
- "Subject\0[PATCH 0/3] Enable namespaced file capabilities\0"
+ "From\0Serge E. Hallyn <serge@hallyn.com>\0"
+ "Subject\0Re: [PATCH 0/3] Enable namespaced file capabilities\0"
  "Date\0Thu, 22 Jun 2017 20:19:24 -0500\0"
- "To\0linux-security-module@vger.kernel.org\0"
+ "To\0James Bottomley <James.Bottomley@hansenpartnership.com>\0"
+ "Cc\0Serge E. Hallyn <serge@hallyn.com>"
+  zohar@linux.vnet.ibm.com
+  containers@lists.linux-foundation.org
+  linux-kernel@vger.kernel.org
+  xiaolong.ye@intel.com
+  linux-security-module@vger.kernel.org
+  ebiederm@xmission.com
+ " lkp@01.org\0"
  "\00:1\0"
  "b\0"
- "Quoting James Bottomley (James.Bottomley at HansenPartnership.com):\n"
+ "Quoting James Bottomley (James.Bottomley@HansenPartnership.com):\n"
  "> On Thu, 2017-06-22 at 18:36 -0500, Serge E. Hallyn wrote:\n"
  "> > Yes, the use case is: to allow root in the container to set the\n"
  "> > privilege itself, without endangering any resources not owned by\n"
@@ -36,7 +44,7 @@
  "> to subsets of these.\n"
  "\n"
  "Hm. In that case they should not be allowed to write your proposed\n"
- "'security.capability at uid' capability, because that would also grant\n"
+ "'security.capability@uid' capability, because that would also grant\n"
  "capabilities over subuids which they were not delegated.\n"
  "\n"
  "(but see below)\n"
@@ -54,15 +62,11 @@
  "> can't see we'd be mixing use cases in a physical system.\n"
  "\n"
  "I might be confused.  But thought CAP_SETFCAP against init_user_ns would\n"
- "be required to set 'security.capability at uid'.  That, or you could create\n"
+ "be required to set 'security.capability@uid'.  That, or you could create\n"
  "a user namespace mapping [ 1 - 4294967295 ] to [ 0 = 4294967294 ], and\n"
  "have CAP_SETFCAP against that namespace.  Which would allow you to run\n"
  "without host root privilege.\n"
  "\n"
- "-serge\n"
- "--\n"
- "To unsubscribe from this list: send the line \"unsubscribe linux-security-module\" in\n"
- "the body of a message to majordomo at vger.kernel.org\n"
- More majordomo info at  http://vger.kernel.org/majordomo-info.html
+ -serge
 
-e0c665074defb94973515b6b19c791eab60be90a605f5a80a7b7f126d37393a0
+89a8b97fe48cfa8134aff423fd5d9949a79a4fb0eda9bec8798b32c81b4ca65c

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.