[Top] [All Lists]

[PATCH v3, 00/16] xfsprogs: fix obfuscation problems in metadump

To: xfs@xxxxxxxxxxx
Subject: [PATCH v3, 00/16] xfsprogs: fix obfuscation problems in metadump
From: Alex Elder <aelder@xxxxxxx>
Date: Fri, 18 Feb 2011 15:21:01 -0600
User-agent: Heirloom mailx 12.5 7/5/10
This series has expanded yet again, but I hope I'm now done with
it.  I'd really like to get it reviewed this time around.  I've
sent out a test for xfstests to verify it this time around...

The main change this time is that I've rearranged the way duplicate
names are handled once they have been obfuscated.  There is a chance
that the result of an obfuscation would be a name that already had
been stored in the names table.  It used to be in that case another
obfuscation attempt was made, but due to limitations in the
algorithm there was a small possibility that no alternative would
be available.  In that case, a duplicate name would be produced
in the metadump file; the duplicates would show up in the
reincarnated filesystem produced by xfs_mdrestore, and would be
identified as problems by xfs_repair.

So there are a few new patches that address this, with some of
them just preparatory work in support of the one that contains
the real changes.

Since the last time it got posted, these changes have been made:
- I've gone over various descriptions in the patches and in the
  comments in the code, and have refined them in hopes it will
  make the whole thing a lot clearer.  Some of this stuff is
  hard to describe.
- Fixed a problem with treatment of the "lost+found" directory
  that cropped up in the last posting.
- Dropped a change that fixed a compile warning.
- Parts of the code have been rearranged, separating the obfuscation
  step from the process of identifying an alternate name if a
  duplicate is found.
- Alternate names are now generated using a methodical process that
  will produce a large number of possibilities, many more than were
  allowed before.  This should avoid ever running into the case
  where duplicates ever wind up in a metadump file.

Below is some of the text I sent last time I posted this series.


My original purpose was to fix a bug in the function used by
xfs_metadump to obfuscate file and extended attribute names.
Arkadiusz Miśkiewicz found out that when he attempted to perform a
metadump on a filesystem which had some files whose names used 8-bit
characters, it never completed.  The cause was a flaw in the
algorithm used to obfuscate names which caused an infinite loop when
certain names got obfuscated.

I have fixed that bug (in patch 4 of this series), but while I was
at it I rearranged the code a bit and did some other cleanups.  The
first 7 patches in the series are really pretty directly related to
that issue.

But while in there I noticed some other somewhat subtle issues and
have addressed those in this series as well:
- There is a table that tracks names to ensure duplicates aren't
  produced as a result of obfuscation.  There was a case where a
  failure to update the table was silently ignored.
- There was still a chance that pathological cases could end up
  repeating due to finding duplicates.  I changed it so it would
  give up after a fixed number of attempts.
- Obfuscated names had been chosen from an alphabet of all allowable
  characters.  This was more than needed, so I made it create names
  that were (mostly) printables.
- It was previously possible for an obfuscated name to end up being
  a duplicate of a real name, because non-obfuscated names were not
  placed in the name table.

And finally I did a little tidying of the code that manages the name

<Prev in Thread] Current Thread [Next in Thread>
  • [PATCH v3, 00/16] xfsprogs: fix obfuscation problems in metadump, Alex Elder <=