* Scrubbing filenames from meta-data dump of ext4 filesystems @ 2021-03-08 20:01 George Goffe 2021-03-08 21:40 ` Theodore Ts'o 0 siblings, 1 reply; 4+ messages in thread From: George Goffe @ 2021-03-08 20:01 UTC (permalink / raw) To: linux-ext4 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? Your help is appreciated. Best regards, George... -- It's not what you know that hurts you, it's what you KNOW that AINT so. WIll Rodgers ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Scrubbing filenames from meta-data dump of ext4 filesystems 2021-03-08 20:01 Scrubbing filenames from meta-data dump of ext4 filesystems George Goffe @ 2021-03-08 21:40 ` Theodore Ts'o 2021-03-09 8:37 ` Andreas Dilger 0 siblings, 1 reply; 4+ messages in thread From: Theodore Ts'o @ 2021-03-08 21:40 UTC (permalink / raw) To: George Goffe; +Cc: linux-ext4 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Scrubbing filenames from meta-data dump of ext4 filesystems 2021-03-08 21:40 ` Theodore Ts'o @ 2021-03-09 8:37 ` Andreas Dilger 2021-03-10 17:11 ` George Goffe 0 siblings, 1 reply; 4+ messages in thread From: Andreas Dilger @ 2021-03-09 8:37 UTC (permalink / raw) To: Theodore Ts'o; +Cc: George Goffe, linux-ext4 [-- Attachment #1: Type: text/plain, Size: 2028 bytes --] On Mar 8, 2021, at 2:40 PM, Theodore Ts'o <tytso@mit.edu> wrote: > > 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. I had actually looked for this option in the e2image man page in order to reply to this email, but I couldn't find it and wondered if I had mis-remembered the existence of this functionality. I've pushed a patch that reorganizes the e2image man page to list all of the options explicitly in a separate OPTIONS section, rather than putting them inline in the text, which makes it hard to find them. Cheers, Andreas > 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 Cheers, Andreas [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 873 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Scrubbing filenames from meta-data dump of ext4 filesystems 2021-03-09 8:37 ` Andreas Dilger @ 2021-03-10 17:11 ` George Goffe 0 siblings, 0 replies; 4+ messages in thread From: George Goffe @ 2021-03-10 17:11 UTC (permalink / raw) To: Andreas Dilger; +Cc: Theodore Ts'o, linux-ext4 Andreas, Thank you for all your help! Best regards, George... On Tue, Mar 9, 2021 at 12:37 AM Andreas Dilger <adilger@dilger.ca> wrote: > > On Mar 8, 2021, at 2:40 PM, Theodore Ts'o <tytso@mit.edu> wrote: > > > > 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. > > I had actually looked for this option in the e2image man page in order > to reply to this email, but I couldn't find it and wondered if I had > mis-remembered the existence of this functionality. > > I've pushed a patch that reorganizes the e2image man page to list all > of the options explicitly in a separate OPTIONS section, rather than > putting them inline in the text, which makes it hard to find them. > > Cheers, Andreas > > > 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 > > > Cheers, Andreas > > > > > -- It's not what you know that hurts you, it's what you KNOW that AINT so. WIll Rodgers ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-03-10 17:12 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-03-08 20:01 Scrubbing filenames from meta-data dump of ext4 filesystems George Goffe 2021-03-08 21:40 ` Theodore Ts'o 2021-03-09 8:37 ` Andreas Dilger 2021-03-10 17:11 ` George Goffe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox