All of lore.kernel.org
 help / color / mirror / Atom feed
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.