From: "Theodore Ts'o" <tytso@mit.edu>
To: George Goffe <grgoffe@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Scrubbing filenames from meta-data dump of ext4 filesystems
Date: Mon, 8 Mar 2021 16:40:49 -0500 [thread overview]
Message-ID: <YEaZ4RL3ZfXB8jdw@mit.edu> (raw)
In-Reply-To: <CALCFxS7EwQbF47GNgaiuOVrw0n=OQBzHTH6JpoeiZ=tb1CYB1g@mail.gmail.com>
On Mon, Mar 08, 2021 at 12:01:46PM -0800, George Goffe wrote:
> Howdy,
>
> I'm helping to shoot a bug on a Fedora Core 35 system and have been
> requested to provide a meta-data dump of the problem filesystem. The
> filenames are restricted so I need to scrub this file before sending
> it.
>
> Does ext4 have a facility whereby I can scrub the filenames from the dump?
Yes, please see the following excerpt from the e2image man page:
This will only send the metadata information, without any data
blocks. However, the filenames in the directory blocks can still
reveal information about the contents of the filesystem that the
bug reporter may wish to keep confidential. To address this
concern, the -s option can be specified. This will cause e2image
to scramble directory entries and zero out any unused portions of
the directory blocks before writing the image file. However, the
-s option will prevent analysis of problems related to hash-tree
indexed directories.
The -s option can be used with the -r and -Q options to e2image, for
creating raw and qcow2 image dumps, respectively. Because the
filenames have been scrambled, this will invalidate the hash-tree
indexes for the directory, so e2fsck will complain about this. But
for some kinds of corruption, the -s option can provide data when the
customer would otherwise not be willing to provide a metadata-only
dump of the file system.
Hope this helps,
- Ted
next prev parent reply other threads:[~2021-03-08 21:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-08 20:01 Scrubbing filenames from meta-data dump of ext4 filesystems George Goffe
2021-03-08 21:40 ` Theodore Ts'o [this message]
2021-03-09 8:37 ` Andreas Dilger
2021-03-10 17:11 ` George Goffe
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=YEaZ4RL3ZfXB8jdw@mit.edu \
--to=tytso@mit.edu \
--cc=grgoffe@gmail.com \
--cc=linux-ext4@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