From: Brian Foster <bfoster@redhat.com>
To: Jan Tulak <jtulak@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/2] xfsprogs: update man for metadump about dirty log/obfuscation issue
Date: Thu, 13 Apr 2017 09:04:07 -0400 [thread overview]
Message-ID: <20170413130407.GC24893@bfoster.bfoster> (raw)
In-Reply-To: <CACj3i70UdyecqPjxNG9c=7gWdi1sjigFAPQX+TWYP0omj_2WvQ@mail.gmail.com>
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
next prev parent reply other threads:[~2017-04-13 13:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-13 8:13 [PATCH 0/2 v2] xfsprogs: metadump warns about dirty journal Jan Tulak
2017-04-13 8:13 ` [PATCH 1/2] metadump: warn about corruption if log is dirty Jan Tulak
2017-04-13 11:54 ` Brian Foster
2017-06-15 0:06 ` Eric Sandeen
2017-06-15 11:23 ` Brian Foster
2017-04-13 8:13 ` [PATCH 2/2] xfsprogs: update man for metadump about dirty log/obfuscation issue Jan Tulak
2017-04-13 12:01 ` Brian Foster
2017-04-13 12:29 ` Jan Tulak
2017-04-13 13:04 ` Brian Foster [this message]
2017-04-13 13:49 ` Eric Sandeen
2017-04-13 15:50 ` Darrick J. Wong
2017-04-13 17:01 ` Eric Sandeen
2017-04-13 17:06 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170413130407.GC24893@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=jtulak@redhat.com \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).