diff for duplicates of <1517845858.3050.13.camel@HansenPartnership.com> diff --git a/a/1.txt b/N1/1.txt index db1c99b..e07be5f 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -7,8 +7,8 @@ Using the presence or absence of d_revalidate isn't definitive for uncacheable appraisals: all stacked filesystems have to implement d_revalidate just in case the underlying has it, but it doesn't mean their appraisals can't be cached if they're fully built on top of -traditional filesystems (like they are in the Docker/OCI use case). I -think the original flag approach is better. The only thing stackable +traditional filesystems (like they are in the Docker/OCI use case). ?I +think the original flag approach is better. ?The only thing stackable filesystems argues for is that for them it should probably be a superblock flag so it can be per-mount point (depending on overlay composition). @@ -16,6 +16,11 @@ composition). d_revalidate() also strikes me as wrong from the semantic point of view: it's about whether the path name to inode cache needs re- evaluating not whether the underlying inode could change arbitrarily. - These are definitely related but not necessarily equivalent concepts. +?These are definitely related but not necessarily equivalent concepts. James + +-- +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 0afbf41..00c9c93 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,14 +1,8 @@ "ref\01517838054.3736.49.camel@linux.vnet.ibm.com\0" - "From\0James Bottomley <James.Bottomley@hansenpartnership.com>\0" - "Subject\0Re: [RFC PATCH] ima: force the re-evaluation of files on untrusted file systems\0" + "From\0James.Bottomley@hansenpartnership.com (James Bottomley)\0" + "Subject\0[RFC PATCH] ima: force the re-evaluation of files on untrusted file systems\0" "Date\0Mon, 05 Feb 2018 15:50:58 +0000\0" - "To\0Mimi Zohar <zohar@linux.vnet.ibm.com>" - " Miklos Szeredi <miklos@szeredi.hu>\0" - "Cc\0Alban Crequy <alban@kinvolk.io>" - Dongsu Park <dongsu@kinvolk.io> - linux-integrity <linux-integrity@vger.kernel.org> - linux-security-module <linux-security-module@vger.kernel.org> - " linux-fsdevel <linux-fsdevel@vger.kernel.org>\0" + "To\0linux-security-module@vger.kernel.org\0" "\00:1\0" "b\0" "On Mon, 2018-02-05 at 08:40 -0500, Mimi Zohar wrote:\n" @@ -20,8 +14,8 @@ "uncacheable appraisals: all stacked filesystems have to implement\n" "d_revalidate just in case the underlying has it, but it doesn't mean\n" "their appraisals can't be cached if they're fully built on top of\n" - "traditional filesystems (like they are in the Docker/OCI use case). I\n" - "think the original flag approach is better. The only thing stackable\n" + "traditional filesystems (like they are in the Docker/OCI use case). ?I\n" + "think the original flag approach is better. ?The only thing stackable\n" "filesystems argues for is that for them it should probably be a\n" "superblock flag so it can be per-mount point (depending on overlay\n" "composition).\n" @@ -29,8 +23,13 @@ "d_revalidate() also strikes me as wrong from the semantic point of\n" "view: it's about whether the path name to inode cache needs re-\n" "evaluating not whether the underlying inode could change arbitrarily.\n" - " These are definitely related but not necessarily equivalent concepts.\n" + "?These are definitely related but not necessarily equivalent concepts.\n" "\n" - James + "James\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 -4e1e152f6273e3083e0359d9ee091599ddbe523592885988ce14945831a62f48 +74558bfa8d7a0244cf4ff2855331443dfed21b13fde5e4c3eb6dadf1a072e684
diff --git a/a/1.txt b/N2/1.txt index db1c99b..4eff356 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -7,8 +7,8 @@ Using the presence or absence of d_revalidate isn't definitive for uncacheable appraisals: all stacked filesystems have to implement d_revalidate just in case the underlying has it, but it doesn't mean their appraisals can't be cached if they're fully built on top of -traditional filesystems (like they are in the Docker/OCI use case). I -think the original flag approach is better. The only thing stackable +traditional filesystems (like they are in the Docker/OCI use case). I +think the original flag approach is better. The only thing stackable filesystems argues for is that for them it should probably be a superblock flag so it can be per-mount point (depending on overlay composition). @@ -16,6 +16,6 @@ composition). d_revalidate() also strikes me as wrong from the semantic point of view: it's about whether the path name to inode cache needs re- evaluating not whether the underlying inode could change arbitrarily. - These are definitely related but not necessarily equivalent concepts. + These are definitely related but not necessarily equivalent concepts. James diff --git a/a/content_digest b/N2/content_digest index 0afbf41..30975bb 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -20,8 +20,8 @@ "uncacheable appraisals: all stacked filesystems have to implement\n" "d_revalidate just in case the underlying has it, but it doesn't mean\n" "their appraisals can't be cached if they're fully built on top of\n" - "traditional filesystems (like they are in the Docker/OCI use case). I\n" - "think the original flag approach is better. The only thing stackable\n" + "traditional filesystems (like they are in the Docker/OCI use case). \302\240I\n" + "think the original flag approach is better. \302\240The only thing stackable\n" "filesystems argues for is that for them it should probably be a\n" "superblock flag so it can be per-mount point (depending on overlay\n" "composition).\n" @@ -29,8 +29,8 @@ "d_revalidate() also strikes me as wrong from the semantic point of\n" "view: it's about whether the path name to inode cache needs re-\n" "evaluating not whether the underlying inode could change arbitrarily.\n" - " These are definitely related but not necessarily equivalent concepts.\n" + "\302\240These are definitely related but not necessarily equivalent concepts.\n" "\n" James -4e1e152f6273e3083e0359d9ee091599ddbe523592885988ce14945831a62f48 +70e61b54e0b5e96eeb4b95136179f7569f5daeedec7d74f321f10831dde15d97
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.