linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).