| Message ID | 20170413081354.22170-3-jtulak@redhat.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Thu, Apr 13, 2017 at 10:13:54AM +0200, Jan Tulak wrote: > This is something that should be documented, as it is not obvious to > everyone. > > Signed-off-by: Jan Tulak <jtulak@redhat.com> > --- > man/man8/xfs_metadump.8 | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/man/man8/xfs_metadump.8 b/man/man8/xfs_metadump.8 > index 3731d6a..1b40fb8 100644 > --- a/man/man8/xfs_metadump.8 > +++ b/man/man8/xfs_metadump.8 > @@ -59,6 +59,12 @@ options where > are not obfuscated. Names between 5 and 8 characters in length inclusively > are partially obfuscated. > .PP > +Log recovery of an obfuscated metadata image can leak > +unobfuscated metadata and/or cause image corruption. Please mount > +the source filesystem to clean the log or disable obfuscation, if possible. > +If you have to obfuscate an image with a dirty log, tell about it to whoever > +you are sending the image to. > +.PP We might want the man page content to be a bit more descriptive than what xfs_metadump actually emits for a warning. For example: "xfs_metadump does not obfuscate data in the filesystem log. Log recovery of an obfuscated metadump image may expose unobfuscated metadata and/or cause filesystem corruption. It is recommended to disable obfuscation for filesystems that must be captured with a dirty log." ... but that's just my .02. Feel free to reword that and solicit more feedback from others too. Another thought here could be to intimate that if an obfuscated+dirty log metadump image is truly required, it is the user responsibility to verify that the resulting image has not been corrupted by the metadump process and does not contain sensitive metadata (as opposed to telling the user to simply tell the recipient of the image about it). Brian > .B xfs_metadump > should not be used for any purposes other than for debugging and reporting > filesystem problems. The most common usage scenario for this tool is when > -- > 2.1.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 13, 2017 at 2:01 PM, Brian Foster <bfoster@redhat.com> wrote: > On Thu, Apr 13, 2017 at 10:13:54AM +0200, Jan Tulak wrote: >> This is something that should be documented, as it is not obvious to >> everyone. >> >> Signed-off-by: Jan Tulak <jtulak@redhat.com> >> --- >> man/man8/xfs_metadump.8 | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/man/man8/xfs_metadump.8 b/man/man8/xfs_metadump.8 >> index 3731d6a..1b40fb8 100644 >> --- a/man/man8/xfs_metadump.8 >> +++ b/man/man8/xfs_metadump.8 >> @@ -59,6 +59,12 @@ options where >> are not obfuscated. Names between 5 and 8 characters in length inclusively >> are partially obfuscated. >> .PP >> +Log recovery of an obfuscated metadata image can leak >> +unobfuscated metadata and/or cause image corruption. Please mount >> +the source filesystem to clean the log or disable obfuscation, if possible. >> +If you have to obfuscate an image with a dirty log, tell about it to whoever >> +you are sending the image to. >> +.PP > > We might want the man page content to be a bit more descriptive than > what xfs_metadump actually emits for a warning. For example: > > "xfs_metadump does not obfuscate data in the filesystem log. Log > recovery of an obfuscated metadump image may expose unobfuscated > metadata and/or cause filesystem corruption. It is recommended to > disable obfuscation for filesystems that must be captured with a dirty > log." > > ... but that's just my .02. Feel free to reword that and solicit more > feedback from others too. Another thought here could be to intimate that > if an obfuscated+dirty log metadump image is truly required, it is the > user responsibility to verify that the resulting image has not been > corrupted by the metadump process and does not contain sensitive > metadata (as opposed to telling the user to simply tell the recipient of > the image about it). > Sounds reasonable, so how about these two paragraphs? > "xfs_metadump does not obfuscate data in the filesystem log. Log > recovery of an obfuscated metadump image may expose unobfuscated > metadata and/or cause filesystem corruption. It is recommended to > disable obfuscation for filesystems that must be captured with a dirty > log. If it is necessary to use obfuscation for any reason and the source fileystem can't be mounted to clean the log, the resulting image should be tested for any corruption caused by metadump process and any sensitive information in the log and the recipient of the image informed about the result." Cheers, Jan
On Thu, Apr 13, 2017 at 02:29:34PM +0200, Jan Tulak wrote: > On Thu, Apr 13, 2017 at 2:01 PM, Brian Foster <bfoster@redhat.com> wrote: > > On Thu, Apr 13, 2017 at 10:13:54AM +0200, Jan Tulak wrote: > >> This is something that should be documented, as it is not obvious to > >> everyone. > >> > >> Signed-off-by: Jan Tulak <jtulak@redhat.com> > >> --- > >> man/man8/xfs_metadump.8 | 6 ++++++ > >> 1 file changed, 6 insertions(+) > >> > >> diff --git a/man/man8/xfs_metadump.8 b/man/man8/xfs_metadump.8 > >> index 3731d6a..1b40fb8 100644 > >> --- a/man/man8/xfs_metadump.8 > >> +++ b/man/man8/xfs_metadump.8 > >> @@ -59,6 +59,12 @@ options where > >> are not obfuscated. Names between 5 and 8 characters in length inclusively > >> are partially obfuscated. > >> .PP > >> +Log recovery of an obfuscated metadata image can leak > >> +unobfuscated metadata and/or cause image corruption. Please mount > >> +the source filesystem to clean the log or disable obfuscation, if possible. > >> +If you have to obfuscate an image with a dirty log, tell about it to whoever > >> +you are sending the image to. > >> +.PP > > > > We might want the man page content to be a bit more descriptive than > > what xfs_metadump actually emits for a warning. For example: > > > > "xfs_metadump does not obfuscate data in the filesystem log. Log > > recovery of an obfuscated metadump image may expose unobfuscated > > metadata and/or cause filesystem corruption. It is recommended to > > disable obfuscation for filesystems that must be captured with a dirty > > log." > > > > ... but that's just my .02. Feel free to reword that and solicit more > > feedback from others too. Another thought here could be to intimate that > > if an obfuscated+dirty log metadump image is truly required, it is the > > user responsibility to verify that the resulting image has not been > > corrupted by the metadump process and does not contain sensitive > > metadata (as opposed to telling the user to simply tell the recipient of > > the image about it). > > > > Sounds reasonable, so how about these two paragraphs? > > > "xfs_metadump does not obfuscate data in the filesystem log. Log > > recovery of an obfuscated metadump image may expose unobfuscated > > metadata and/or cause filesystem corruption. It is recommended to > > disable obfuscation for filesystems that must be captured with a dirty > > log. > > If it is necessary to use obfuscation for any reason and the source fileystem > can't be mounted to clean the log, the resulting image should be tested for > any corruption caused by metadump process and any sensitive information > in the log and the recipient of the image informed about the result." > You might want to give Eric/Darrick some time to provide feedback before sending out a new version, but otherwise that works for me. Thanks! Brian > Cheers, > Jan > > -- > Jan Tulak > jtulak@redhat.com / jan@tulak.me > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 4/13/17 7:29 AM, Jan Tulak wrote: > On Thu, Apr 13, 2017 at 2:01 PM, Brian Foster <bfoster@redhat.com> wrote: >> On Thu, Apr 13, 2017 at 10:13:54AM +0200, Jan Tulak wrote: >>> This is something that should be documented, as it is not obvious to >>> everyone. >>> >>> Signed-off-by: Jan Tulak <jtulak@redhat.com> >>> --- >>> man/man8/xfs_metadump.8 | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/man/man8/xfs_metadump.8 b/man/man8/xfs_metadump.8 >>> index 3731d6a..1b40fb8 100644 >>> --- a/man/man8/xfs_metadump.8 >>> +++ b/man/man8/xfs_metadump.8 >>> @@ -59,6 +59,12 @@ options where >>> are not obfuscated. Names between 5 and 8 characters in length inclusively >>> are partially obfuscated. >>> .PP >>> +Log recovery of an obfuscated metadata image can leak >>> +unobfuscated metadata and/or cause image corruption. Please mount >>> +the source filesystem to clean the log or disable obfuscation, if possible. >>> +If you have to obfuscate an image with a dirty log, tell about it to whoever >>> +you are sending the image to. >>> +.PP >> >> We might want the man page content to be a bit more descriptive than >> what xfs_metadump actually emits for a warning. For example: >> >> "xfs_metadump does not obfuscate data in the filesystem log. Log >> recovery of an obfuscated metadump image may expose unobfuscated >> metadata and/or cause filesystem corruption. It is recommended to >> disable obfuscation for filesystems that must be captured with a dirty >> log." >> >> ... but that's just my .02. Feel free to reword that and solicit more >> feedback from others too. Another thought here could be to intimate that >> if an obfuscated+dirty log metadump image is truly required, it is the >> user responsibility to verify that the resulting image has not been >> corrupted by the metadump process and does not contain sensitive >> metadata (as opposed to telling the user to simply tell the recipient of >> the image about it). >> > > Sounds reasonable, so how about these two paragraphs? > >> "xfs_metadump does not obfuscate data metadata >> in the filesystem log. Log >> recovery of an obfuscated metadump image may expose unobfuscated >> metadata and/or cause filesystem corruption. I would add "in the restored image." so that it does not sound like damage to the original filesystem could result. > It is recommended to >> disable obfuscation for filesystems that must be captured with a dirty >> log. > > If it is necessary to use obfuscation for any reason drop "for any reason" - just makes this long text longer... > and the source fileystem > can't be mounted to clean the log, the resulting image should be tested for > any corruption caused by metadump process and any sensitive information > in the log and the recipient of the image informed about the result." The end-user running metadump may not have the expertise to "test the resulting image for any corruption ..." - they're probably just following some support person's instructions to "run this command..." How about this: --- xfs_metadump cannot obfuscate metadata in the filesystem log. Log recovery of an obfuscated metadump image may expose clear-text metadata and/or cause filesystem corruption in the restored image. It is recommended that the source filesystem be mounted and unmounted first if possible, to produce a metadump with a clean log. If a metadump must be produced from a filesystem with a dirty log, it is recommended that obfuscation be turned off with -o option, if metadata such as filenames is not considered sensitive. If obfuscation is required on a metadump with a dirty log, please inform the recipient of the metadump image about this situation. --- -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 13, 2017 at 08:49:52AM -0500, Eric Sandeen wrote: > On 4/13/17 7:29 AM, Jan Tulak wrote: > > On Thu, Apr 13, 2017 at 2:01 PM, Brian Foster <bfoster@redhat.com> wrote: > >> On Thu, Apr 13, 2017 at 10:13:54AM +0200, Jan Tulak wrote: > >>> This is something that should be documented, as it is not obvious to > >>> everyone. > >>> > >>> Signed-off-by: Jan Tulak <jtulak@redhat.com> > >>> --- > >>> man/man8/xfs_metadump.8 | 6 ++++++ > >>> 1 file changed, 6 insertions(+) > >>> > >>> diff --git a/man/man8/xfs_metadump.8 b/man/man8/xfs_metadump.8 > >>> index 3731d6a..1b40fb8 100644 > >>> --- a/man/man8/xfs_metadump.8 > >>> +++ b/man/man8/xfs_metadump.8 > >>> @@ -59,6 +59,12 @@ options where > >>> are not obfuscated. Names between 5 and 8 characters in length inclusively > >>> are partially obfuscated. > >>> .PP > >>> +Log recovery of an obfuscated metadata image can leak > >>> +unobfuscated metadata and/or cause image corruption. Please mount > >>> +the source filesystem to clean the log or disable obfuscation, if possible. > >>> +If you have to obfuscate an image with a dirty log, tell about it to whoever > >>> +you are sending the image to. > >>> +.PP > >> > >> We might want the man page content to be a bit more descriptive than > >> what xfs_metadump actually emits for a warning. For example: > >> > >> "xfs_metadump does not obfuscate data in the filesystem log. Log > >> recovery of an obfuscated metadump image may expose unobfuscated > >> metadata and/or cause filesystem corruption. It is recommended to > >> disable obfuscation for filesystems that must be captured with a dirty > >> log." > >> > >> ... but that's just my .02. Feel free to reword that and solicit more > >> feedback from others too. Another thought here could be to intimate that > >> if an obfuscated+dirty log metadump image is truly required, it is the > >> user responsibility to verify that the resulting image has not been > >> corrupted by the metadump process and does not contain sensitive > >> metadata (as opposed to telling the user to simply tell the recipient of > >> the image about it). > >> > > > > Sounds reasonable, so how about these two paragraphs? > > > >> "xfs_metadump does not obfuscate data > > metadata > > >> in the filesystem log. Log > >> recovery of an obfuscated metadump image may expose unobfuscated > >> metadata and/or cause filesystem corruption. > > I would add "in the restored image." so that it does not sound like > damage to the original filesystem could result. > > > It is recommended to > >> disable obfuscation for filesystems that must be captured with a dirty > >> log. > > > > If it is necessary to use obfuscation for any reason > > drop "for any reason" - just makes this long text longer... > > > and the source fileystem > > can't be mounted to clean the log, the resulting image should be tested for > > any corruption caused by metadump process and any sensitive information > > in the log and the recipient of the image informed about the result." > > The end-user running metadump may not have the expertise to "test the resulting > image for any corruption ..." - they're probably just following some support > person's instructions to "run this command..." How about this: (Or they're just running some crazy hoover-up-all-the-state script that support gave them. ;)) > --- > > xfs_metadump cannot obfuscate metadata in the filesystem log. Log > recovery of an obfuscated metadump image may expose clear-text > metadata and/or cause filesystem corruption in the restored image. > It is recommended that the source filesystem be mounted and unmounted > first if possible, to produce a metadump with a clean log. "It is recommended that the source filesystem first be mounted and unmounted, if possible, to ensure that the log is clean. That way, all metadata can be obfuscated correctly and the metadump will capture a clean log." ...because mounting and unmounting itself does not produce metadumps. :) > If a metadump must be produced from a filesystem with a dirty log, > it is recommended that obfuscation be turned off with -o option, if > metadata such as filenames is not considered sensitive. If obfuscation > is required on a metadump with a dirty log, please inform the recipient > of the metadump image about this situation. Otherwise seems fine to me. --D > --- > > -Eric > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 4/13/17 10:50 AM, Darrick J. Wong wrote: > On Thu, Apr 13, 2017 at 08:49:52AM -0500, Eric Sandeen wrote: >> --- >> >> xfs_metadump cannot obfuscate metadata in the filesystem log. Log >> recovery of an obfuscated metadump image may expose clear-text >> metadata and/or cause filesystem corruption in the restored image. >> It is recommended that the source filesystem be mounted and unmounted >> first if possible, to produce a metadump with a clean log. > > "It is recommended that the source filesystem first be mounted and > unmounted, if possible, to ensure that the log is clean. That way, all > metadata can be obfuscated correctly and the metadump will capture a > clean log." > > ...because mounting and unmounting itself does not produce metadumps. :) That was the "first" bit, but "That way" is a bit colloquial IMHO. <full_pedant_mode> How about: "It is recommended that the source filesystem first be mounted and unmounted, if possible, to ensure that the log is clean. After that operation, all metadata will be obfuscated correctly and xfs_metadump will capture a clean log." -Eric >> If a metadump must be produced from a filesystem with a dirty log, >> it is recommended that obfuscation be turned off with -o option, if >> metadata such as filenames is not considered sensitive. If obfuscation >> is required on a metadump with a dirty log, please inform the recipient >> of the metadump image about this situation. > > Otherwise seems fine to me. > > --D > >> --- >> >> -Eric >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Apr 13, 2017 at 12:01:32PM -0500, Eric Sandeen wrote: > On 4/13/17 10:50 AM, Darrick J. Wong wrote: > > On Thu, Apr 13, 2017 at 08:49:52AM -0500, Eric Sandeen wrote: > > >> --- > >> > >> xfs_metadump cannot obfuscate metadata in the filesystem log. Log > >> recovery of an obfuscated metadump image may expose clear-text > >> metadata and/or cause filesystem corruption in the restored image. > >> It is recommended that the source filesystem be mounted and unmounted > >> first if possible, to produce a metadump with a clean log. > > > > "It is recommended that the source filesystem first be mounted and > > unmounted, if possible, to ensure that the log is clean. That way, all > > metadata can be obfuscated correctly and the metadump will capture a > > clean log." > > > > ...because mounting and unmounting itself does not produce metadumps. :) > > That was the "first" bit, but "That way" is a bit colloquial IMHO. > <full_pedant_mode> > > How about: > > "It is recommended that the source filesystem first be mounted and > unmounted, if possible, to ensure that the log is clean. After that > operation, all metadata will be obfuscated correctly and xfs_metadump > will capture a clean log." "A subsequent invocation of xfs_metadump will capture a clean log and obfuscate all metadata correctly." More bikeshedding! Yay! :) --D > > -Eric > > > >> If a metadump must be produced from a filesystem with a dirty log, > >> it is recommended that obfuscation be turned off with -o option, if > >> metadata such as filenames is not considered sensitive. If obfuscation > >> is required on a metadump with a dirty log, please inform the recipient > >> of the metadump image about this situation. > > > > Otherwise seems fine to me. > > > > --D > > > >> --- > >> > >> -Eric > >> -- > >> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > >> the body of a message to majordomo@vger.kernel.org > >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/man/man8/xfs_metadump.8 b/man/man8/xfs_metadump.8 index 3731d6a..1b40fb8 100644 --- a/man/man8/xfs_metadump.8 +++ b/man/man8/xfs_metadump.8 @@ -59,6 +59,12 @@ options where are not obfuscated. Names between 5 and 8 characters in length inclusively are partially obfuscated. .PP +Log recovery of an obfuscated metadata image can leak +unobfuscated metadata and/or cause image corruption. Please mount +the source filesystem to clean the log or disable obfuscation, if possible. +If you have to obfuscate an image with a dirty log, tell about it to whoever +you are sending the image to. +.PP .B xfs_metadump should not be used for any purposes other than for debugging and reporting filesystem problems. The most common usage scenario for this tool is when
This is something that should be documented, as it is not obvious to everyone. Signed-off-by: Jan Tulak <jtulak@redhat.com> --- man/man8/xfs_metadump.8 | 6 ++++++ 1 file changed, 6 insertions(+)