Re: [PATCH 2/2] xfsprogs: update man for metadump about dirty log/obfuscation issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> 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@xxxxxxxxxx>
> >> ---
> >>  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@xxxxxxxxxx / jan@xxxxxxxx
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux