From: Alex Elder <aelder@sgi.com>
To: xfs@oss.sgi.com
Subject: [PATCH 00/12] xfsprogs: fixup generate_obfuscated_name()
Date: Thu, 30 Dec 2010 14:39:43 -0600 [thread overview]
Message-ID: <1293741583.2294.341.camel@doink> (raw)
This series has expanded some since I first posted a
version of it back in October.
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 table.
Below is a summary of the patches, in order.
-Alex
xfsprogs: some things aren't all that special
Some simple code refactoring to make the purpose
of one help function more focused.
xfsprogs: simplify leading '/' handling in generate_obfuscated_name()
Another cleanup, to simplify some other changes to come.
xfsprogs: drop unneeded use of a random character
This tweaks the obfuscated filename algorithm slightly
to simplify it, while preserving its original properties.
xfsprogs: adjust rather than start over when invalid byte found
This contains the real fix to the original problem. This
patch contains a very long description to explain what's
happening. But basically it changes the algorithm so that
when a bad (random) character is produced, we don't start
over, but instead modify the character (by flipping a bit),
resulting in a good character that will be used.
xfsprogs: eliminate a pointless loop in generate_obfuscated_name()
The previous change made a loop in the code no longer needed.
xfsprogs: Replace repeated blocks with a loop
The code is now structured so all of the last 5 characters
in an obfuscated name are handled identically. This just
takes advantage of that by using a loop over them.
xfsprogs: use pointers in generate_obfuscated_name()
Sort of a cleanup, replacing array references with pointers.
xfsprogs: ensure dup table always has entry for obfuscated name
This just makes sure we create an entry in the name table
before we pass back an obfuscated name.
xfsprogs: don't loop on too many dups
This ensures we don't loop forever (or even for very long)
if we repeatedly come up with duplicate entries when
obfuscating names.
xfsprogs: use printable characters for obfuscated filenames
This restricts the characters used for all but the
last five letters of obfuscated file names to just a
set of printables.
xfsprogs: fix up the nametable code in db/metadump.c
This encapsulates some code that works with the
name table used in tracking duplicates.
xfsprogs: Drop a typedef in db/metadump.c
This just gets rid of an unnecessary typedef.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
reply other threads:[~2010-12-30 20:37 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1293741583.2294.341.camel@doink \
--to=aelder@sgi.com \
--cc=xfs@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.