diff for duplicates of <1517585624.3171.64.camel@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index 7198622..39f62a0 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -13,27 +13,27 @@ On Fri, 2018-02-02 at 10:20 -0500, Mimi Zohar wrote: > > Both IMA-measurement and IMA-appraisal cache the integrity results and > are dependent on the kernel to detect when a file changes in order to -> clear the cached info and force the file to be re-evaluated. This -> detection was dependent on i_version changing. For filesystems that +> clear the cached info and force the file to be re-evaluated.??This +> detection was dependent on i_version changing.??For filesystems that > do not support i_version, remote or fuse filesystems, where the kernel > does not detect the file change, the file was measured and the > signature evaluated just once. > > With commit a2a2c3c8580a ("ima: Use i_version only when filesystem > supports it"), which is being upstreamed in this open window, -> i_version is considered an optimization. If i_version is not enabled, +> i_version is considered an optimization.??If i_version is not enabled, > either because the local filesystem does not support it or the > filesystem wasn't mounted with i_version, the file will now always be > re-evaluated. > > That patch does not address FUSE or remote filesystems, as the kernel -> does not detect the change. Further, even if the kernel could detect +> does not detect the change.??Further, even if the kernel could detect > the change, FUSE filesystems by definition are untrusted. > > The original patches addressed FUSE filesystems, by defining a new IMA > policy option, forcing the file to be re-evaluated based on the -> filesystem magic number. All of the changes were in the IMA -> subsystem. These patches are the result of Christoph's comment on the +> filesystem magic number. ?All of the changes were in the IMA +> subsystem. ?These patches are the result of Christoph's comment on the > original patches saying, "ima has no business looking at either the > name _or_ the magic number." > @@ -48,10 +48,10 @@ Mimi > > > -> > Cc: linux-kernel@vger.kernel.org -> > Cc: linux-integrity@vger.kernel.org -> > Cc: linux-security-module@vger.kernel.org -> > Cc: linux-fsdevel@vger.kernel.org +> > Cc: linux-kernel at vger.kernel.org +> > Cc: linux-integrity at vger.kernel.org +> > Cc: linux-security-module at vger.kernel.org +> > Cc: linux-fsdevel at vger.kernel.org > > Cc: Miklos Szeredi <miklos@szeredi.hu> > > Cc: Alexander Viro <viro@zeniv.linux.org.uk> > > Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> @@ -92,4 +92,9 @@ Mimi > > #define FS_RENAME_DOES_D_MOVE 32768 /* FS will handle d_move() during rename() internally. */ > > struct dentry *(*mount) (struct file_system_type *, int, > > const char *, void *); -> +> + +-- +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 0b6e38e..5eb35df 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,23 +1,10 @@ "ref\0cover.1517314847.git.dongsu@kinvolk.io\0" "ref\086832c6adb256f29f44b6229222b80964fc8cfcc.1517314847.git.dongsu@kinvolk.io\0" "ref\01517584816.3171.61.camel@linux.vnet.ibm.com\0" - "From\0Mimi Zohar <zohar@linux.vnet.ibm.com>\0" - "Subject\0Re: [RFC PATCH v4 1/2] fuse: introduce new fs_type flag FS_IMA_NO_CACHE\0" + "From\0zohar@linux.vnet.ibm.com (Mimi Zohar)\0" + "Subject\0[RFC PATCH v4 1/2] fuse: introduce new fs_type flag FS_IMA_NO_CACHE\0" "Date\0Fri, 02 Feb 2018 10:33:44 -0500\0" - "To\0Miklos Szeredi <miklos@szeredi.hu>" - " Christoph Hellwig <hch@infradead.org>\0" - "Cc\0linux-integrity@vger.kernel.org" - linux-security-module@vger.kernel.org - linux-fsdevel@vger.kernel.org - Alban Crequy <alban@kinvolk.io> - Miklos Szeredi <mszeredi@redhat.com> - Alexander Viro <viro@zeniv.linux.org.uk> - Dmitry Kasatkin <dmitry.kasatkin@gmail.com> - James Morris <jmorris@namei.org> - Serge E . Hallyn <serge@hallyn.com> - Seth Forshee <seth.forshee@canonical.com> - Dongsu Park <dongsu@kinvolk.io> - " linux-kernel@vger.kernel.org\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Fri, 2018-02-02 at 10:20 -0500, Mimi Zohar wrote:\n" @@ -35,27 +22,27 @@ "> \n" "> Both IMA-measurement and IMA-appraisal cache the integrity results and\n" "> are dependent on the kernel to detect when a file changes in order to\n" - "> clear the cached info and force the file to be re-evaluated. This\n" - "> detection was dependent on i_version changing. For filesystems that\n" + "> clear the cached info and force the file to be re-evaluated.??This\n" + "> detection was dependent on i_version changing.??For filesystems that\n" "> do not support i_version, remote or fuse filesystems, where the kernel\n" "> does not detect the file change, the file was measured and the\n" "> signature evaluated just once.\n" "> \n" "> With commit a2a2c3c8580a (\"ima: Use i_version only when filesystem\n" "> supports it\"), which is being upstreamed in this open window,\n" - "> i_version is considered an optimization. If i_version is not enabled,\n" + "> i_version is considered an optimization.??If i_version is not enabled,\n" "> either because the local filesystem does not support it or the\n" "> filesystem wasn't mounted with i_version, the file will now always be\n" "> re-evaluated.\n" "> \n" "> That patch does not address FUSE or remote filesystems, as the kernel\n" - "> does not detect the change. Further, even if the kernel could detect\n" + "> does not detect the change.??Further, even if the kernel could detect\n" "> the change, FUSE filesystems by definition are untrusted.\n" "> \n" "> The original patches addressed FUSE filesystems, by defining a new IMA\n" "> policy option, forcing the file to be re-evaluated based on the\n" - "> filesystem magic number. All of the changes were in the IMA\n" - "> subsystem. These patches are the result of Christoph's comment on the\n" + "> filesystem magic number. ?All of the changes were in the IMA\n" + "> subsystem. ?These patches are the result of Christoph's comment on the\n" "> original patches saying, \"ima has no business looking at either the\n" "> name _or_ the magic number.\"\n" "> \n" @@ -70,10 +57,10 @@ "\n" "> \n" "> > \n" - "> > Cc: linux-kernel@vger.kernel.org\n" - "> > Cc: linux-integrity@vger.kernel.org\n" - "> > Cc: linux-security-module@vger.kernel.org\n" - "> > Cc: linux-fsdevel@vger.kernel.org\n" + "> > Cc: linux-kernel at vger.kernel.org\n" + "> > Cc: linux-integrity at vger.kernel.org\n" + "> > Cc: linux-security-module at vger.kernel.org\n" + "> > Cc: linux-fsdevel at vger.kernel.org\n" "> > Cc: Miklos Szeredi <miklos@szeredi.hu>\n" "> > Cc: Alexander Viro <viro@zeniv.linux.org.uk>\n" "> > Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>\n" @@ -114,6 +101,11 @@ "> > #define FS_RENAME_DOES_D_MOVE\t32768\t/* FS will handle d_move() during rename() internally. */\n" "> > \tstruct dentry *(*mount) (struct file_system_type *, int,\n" "> > \t\t const char *, void *);\n" - > + "> \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 -5f6f5c2dbec69ed41d05fb6147867caa8ee2247559ec88d7d33eb69f2d351b40 +a3858e07aa0418c09e6a44fd1d6333cf84b31ef0b16b14395560c998441c0d16
diff --git a/a/1.txt b/N2/1.txt index 7198622..1734866 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -13,27 +13,27 @@ On Fri, 2018-02-02 at 10:20 -0500, Mimi Zohar wrote: > > Both IMA-measurement and IMA-appraisal cache the integrity results and > are dependent on the kernel to detect when a file changes in order to -> clear the cached info and force the file to be re-evaluated. This -> detection was dependent on i_version changing. For filesystems that +> clear the cached info and force the file to be re-evaluated. This +> detection was dependent on i_version changing. For filesystems that > do not support i_version, remote or fuse filesystems, where the kernel > does not detect the file change, the file was measured and the > signature evaluated just once. > > With commit a2a2c3c8580a ("ima: Use i_version only when filesystem > supports it"), which is being upstreamed in this open window, -> i_version is considered an optimization. If i_version is not enabled, +> i_version is considered an optimization. If i_version is not enabled, > either because the local filesystem does not support it or the > filesystem wasn't mounted with i_version, the file will now always be > re-evaluated. > > That patch does not address FUSE or remote filesystems, as the kernel -> does not detect the change. Further, even if the kernel could detect +> does not detect the change. Further, even if the kernel could detect > the change, FUSE filesystems by definition are untrusted. > > The original patches addressed FUSE filesystems, by defining a new IMA > policy option, forcing the file to be re-evaluated based on the -> filesystem magic number. All of the changes were in the IMA -> subsystem. These patches are the result of Christoph's comment on the +> filesystem magic number. All of the changes were in the IMA +> subsystem. These patches are the result of Christoph's comment on the > original patches saying, "ima has no business looking at either the > name _or_ the magic number." > diff --git a/a/content_digest b/N2/content_digest index 0b6e38e..176ef7a 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -35,27 +35,27 @@ "> \n" "> Both IMA-measurement and IMA-appraisal cache the integrity results and\n" "> are dependent on the kernel to detect when a file changes in order to\n" - "> clear the cached info and force the file to be re-evaluated. This\n" - "> detection was dependent on i_version changing. For filesystems that\n" + "> clear the cached info and force the file to be re-evaluated.\302\240\302\240This\n" + "> detection was dependent on i_version changing.\302\240\302\240For filesystems that\n" "> do not support i_version, remote or fuse filesystems, where the kernel\n" "> does not detect the file change, the file was measured and the\n" "> signature evaluated just once.\n" "> \n" "> With commit a2a2c3c8580a (\"ima: Use i_version only when filesystem\n" "> supports it\"), which is being upstreamed in this open window,\n" - "> i_version is considered an optimization. If i_version is not enabled,\n" + "> i_version is considered an optimization.\302\240\302\240If i_version is not enabled,\n" "> either because the local filesystem does not support it or the\n" "> filesystem wasn't mounted with i_version, the file will now always be\n" "> re-evaluated.\n" "> \n" "> That patch does not address FUSE or remote filesystems, as the kernel\n" - "> does not detect the change. Further, even if the kernel could detect\n" + "> does not detect the change.\302\240\302\240Further, even if the kernel could detect\n" "> the change, FUSE filesystems by definition are untrusted.\n" "> \n" "> The original patches addressed FUSE filesystems, by defining a new IMA\n" "> policy option, forcing the file to be re-evaluated based on the\n" - "> filesystem magic number. All of the changes were in the IMA\n" - "> subsystem. These patches are the result of Christoph's comment on the\n" + "> filesystem magic number. \302\240All of the changes were in the IMA\n" + "> subsystem. \302\240These patches are the result of Christoph's comment on the\n" "> original patches saying, \"ima has no business looking at either the\n" "> name _or_ the magic number.\"\n" "> \n" @@ -116,4 +116,4 @@ "> > \t\t const char *, void *);\n" > -5f6f5c2dbec69ed41d05fb6147867caa8ee2247559ec88d7d33eb69f2d351b40 +1b55f9cfbc7c1ff2fc9bedd99a6026df0719372e704cbe584d1db4011ba77eab
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.