All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1506293706.3893.70.camel@linux.vnet.ibm.com>

diff --git a/a/1.txt b/N1/1.txt
index 692e177..4613ec0 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -56,18 +56,18 @@ On Mon, 2017-09-18 at 10:55 -0400, Mimi Zohar wrote:
 > > Linus wants).
 > 
 > For performance reasons, IMA is not on a write hook, but detects file
-> change on the last __fput() opened for write. ?At that point, the
-> cached info is reset. ?The file hash is re-calculated and written out
-> as an xattr. ?On the next file access (in policy), the file hash is
+> change on the last __fput() opened for write.  At that point, the
+> cached info is reset.  The file hash is re-calculated and written out
+> as an xattr.  On the next file access (in policy), the file hash is
 > re-calculated and stored in the iint.
 > 
 > In terms of remote/clustered/fuse filesystems, we wouldn't be on the
-> __fput() path. ?Support for remote/clustered/fuse filesystems, would
-> be similar to filesystems that do not support i_version. ?Meaning only
+> __fput() path.  Support for remote/clustered/fuse filesystems, would
+> be similar to filesystems that do not support i_version.  Meaning only
 > the first file access (in policy) would be measured/appraised, but not
-> subsequent ones. ?Even if we could detect file change, we would be
+> subsequent ones.  Even if we could detect file change, we would be
 > dependent on the remote/clustered/fuse filesystem to inform us of the
-> change. ?What type of integrity guarantees would that provide?
+> change.  What type of integrity guarantees would that provide?
 
 After thinking this over a bit, perhaps we shouldn't cache the file
 integrity results for these filesystems, since we can't rely on them
@@ -75,8 +75,3 @@ to notify us of a change (eg. malicious fs), but simply re-measure/re-
 validate files each time.
 
 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
diff --git a/a/content_digest b/N1/content_digest
index 03ab43e..3c4c495 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -10,10 +10,36 @@
  "ref\0517c83a6-d7c5-9638-ebaa-52800ca0962c@redhat.com\0"
  "ref\020170918101350.GI32516@quack2.suse.cz\0"
  "ref\01505746542.4200.242.camel@linux.vnet.ibm.com\0"
- "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0"
- "Subject\0[PATCH 3/3] ima: use fs method to read integrity data (updated patch description)\0"
+ "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0"
+ "Subject\0Re: [PATCH 3/3] ima: use fs method to read integrity data (updated patch description)\0"
  "Date\0Sun, 24 Sep 2017 18:55:06 -0400\0"
- "To\0linux-security-module@vger.kernel.org\0"
+ "To\0Jan Kara <jack@suse.cz>"
+ " Steven Whitehouse <swhiteho@redhat.com>\0"
+ "Cc\0Al Viro <viro@zeniv.linux.org.uk>"
+  Linus Torvalds <torvalds@linux-foundation.org>
+  Christoph Hellwig <hch@infradead.org>
+  LSM List <linux-security-module@vger.kernel.org>
+  Christoph Hellwig <hch@lst.de>
+  linux-ima-devel@lists.sourceforge.net
+  James Morris <jmorris@namei.org>
+  Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
+  Matthew Garrett <mjg59@srcf.ucam.org>
+  Jan Kara <jack@suse.com>
+  Theodore Ts'o <tytso@mit.edu>
+  Andreas Dilger <adilger.kernel@dilger.ca>
+  Jaegeuk Kim <jaegeuk@kernel.org>
+  Chao Yu <yuchao0@huawei.com>
+  Bob Peterson <rpeterso@redhat.com>
+  David Woodhouse <dwmw2@infradead.org>
+  Dave Kleikamp <shaggy@kernel.org>
+  Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
+  Mark Fasheh <mfasheh@versity.com>
+  Joel Becker <jlbec@evilplan.org>
+  Richard Weinberger <richard@nod.at>
+  Darrick J. Wong <darrick.wong@oracle.com>
+  Hugh Dickins <hughd@google.com>
+  Chris Mason <clm@fb.com>
+ " Sascha Hauer <s.hauer@pengutronix.de>\0"
  "\00:1\0"
  "b\0"
  "On Mon, 2017-09-18 at 10:55 -0400, Mimi Zohar wrote:\n"
@@ -74,29 +100,24 @@
  "> > Linus wants).\n"
  "> \n"
  "> For performance reasons, IMA is not on a write hook, but detects file\n"
- "> change on the last __fput() opened for write. ?At that point, the\n"
- "> cached info is reset. ?The file hash is re-calculated and written out\n"
- "> as an xattr. ?On the next file access (in policy), the file hash is\n"
+ "> change on the last __fput() opened for write. \302\240At that point, the\n"
+ "> cached info is reset. \302\240The file hash is re-calculated and written out\n"
+ "> as an xattr. \302\240On the next file access (in policy), the file hash is\n"
  "> re-calculated and stored in the iint.\n"
  "> \n"
  "> In terms of remote/clustered/fuse filesystems, we wouldn't be on the\n"
- "> __fput() path. ?Support for remote/clustered/fuse filesystems, would\n"
- "> be similar to filesystems that do not support i_version. ?Meaning only\n"
+ "> __fput() path. \302\240Support for remote/clustered/fuse filesystems, would\n"
+ "> be similar to filesystems that do not support i_version. \302\240Meaning only\n"
  "> the first file access (in policy) would be measured/appraised, but not\n"
- "> subsequent ones. ?Even if we could detect file change, we would be\n"
+ "> subsequent ones. \302\240Even if we could detect file change, we would be\n"
  "> dependent on the remote/clustered/fuse filesystem to inform us of the\n"
- "> change. ?What type of integrity guarantees would that provide?\n"
+ "> change. \302\240What type of integrity guarantees would that provide?\n"
  "\n"
  "After thinking this over a bit, perhaps we shouldn't cache the file\n"
  "integrity results for these filesystems, since we can't rely on them\n"
  "to notify us of a change (eg. malicious fs), but simply re-measure/re-\n"
  "validate files each time.\n"
  "\n"
- "Mimi\n"
- "\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
+ Mimi
 
-89c6d7211a65a57ad216e3cb1a6d3aae5997f8d4027899f3955274d53c2aa074
+069d5f63ef037663710e22b3be3bbc20b68f3eb6e827338987cc78b621839961

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.