On Tue, Jul 25, 2017 at 9:36 AM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote: >> > +++ b/design/XFS_Filesystem_Structure/metadump.asciidoc >> > +== Dump Obfuscation >> > + >> > +Unless explicitly disabled, the +xfs_metadump+ tool obfuscates empty block >> > +space and naming information to avoid leaking sensitive information into >> > +the metadump file. +xfs_metadump+ does not copy user data blocks. >> > + >> > +The obfuscation policy is as follows: >> > + >> > +* File and extended attribute names are both considered "names". >> > +* Names longer than 8 characters are totally rewritten with a name that matches the hash of the old name. >> > +* Names between 5 and 8 characters are partially rewritten to match the hash of the old name. >> >> Any reason for this? > > /me doesn't know. Maybe it's too hard to generate a new name with the > same hash? I just thought of a good reason: shorter names means less information to be able to create a unique hash and avoid clashes. >> > +* Names shorter than 5 characters are not obscured at all. >> >> This does not seem like a good idea, do we have a record of why this was done >> historically? And likewise for smaller number of characters there could be clashes. In fact the latest md5 clash was for 64 bytes. But since we *really* don't want to create a reverse map at all why not just use random characters? Sure we'd eat up entropy fast on a system but it would seem to be a fair requirement to ask for good entropy for this. >> > +* Names that cross a block boundary are not obscured at all. >> >> Likewise. > > iirc we basically copy things a block at a time, which makes it harder > to deal with multi-fsblock dirblocks (???) > > I don't really know, let's see if the list remembers. :) Luis -- 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
