public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: cem@kernel.org, linux-xfs@vger.kernel.org, david@fromorbit.com,
	hch@infradead.org
Subject: Re: [PATCH 3/5] xfs_db: fix metadump name obfuscation for ascii-ci filesystems
Date: Mon, 5 Jun 2023 10:09:48 -0700	[thread overview]
Message-ID: <20230605170948.GL72241@frogsfrogsfrogs> (raw)
In-Reply-To: <99cf8b71-3c8a-7114-c7d1-7078242b9dff@sandeen.net>

On Mon, Jun 05, 2023 at 11:59:45AM -0500, Eric Sandeen wrote:
> On 6/5/23 10:36 AM, Darrick J. Wong wrote:
> > @@ -1205,9 +1264,9 @@ generate_obfuscated_name(
> >   	/* Obfuscate the name (if possible) */
> > -	hash = libxfs_da_hashname(name, namelen);
> > -	obfuscate_name(hash, namelen, name);
> > -	ASSERT(hash == libxfs_da_hashname(name, namelen));
> > +	hash = dirattr_hashname(ino != 0, name, namelen);
> > +	obfuscate_name(hash, namelen, name, ino != 0);
> > +	ASSERT(hash == dirattr_hashname(ino != 0, name, namelen));
> 
> This makes sense to me - comments above here remind us that "inode == 0"
> means we're obfuscating an xattr value, not a filename or path name, but ...
> 
> >   	/*
> >   	 * Make sure the name is not something already seen.  If we
> > @@ -1320,7 +1379,7 @@ obfuscate_path_components(
> >   			/* last (or single) component */
> >   			namelen = strnlen((char *)comp, len);
> >   			hash = libxfs_da_hashname(comp, namelen);
> > -			obfuscate_name(hash, namelen, comp);
> > +			obfuscate_name(hash, namelen, comp, false);
> >   			ASSERT(hash == libxfs_da_hashname(comp, namelen));
> >   			break;
> >   		}
> > @@ -1332,7 +1391,7 @@ obfuscate_path_components(
> >   			continue;
> >   		}
> >   		hash = libxfs_da_hashname(comp, namelen);
> > -		obfuscate_name(hash, namelen, comp);
> > +		obfuscate_name(hash, namelen, comp, false);
> >   		ASSERT(hash == libxfs_da_hashname(comp, namelen));
> >   		comp += namelen + 1;
> >   		len -= namelen + 1;
> > 
> 
> here, why is "is_dirent" false? Shouldn't a symlink path component match the
> associated dirents, and be obsucated the same way?

Name obfuscation replaces every byte except for the last five bytes with
a random printable character, and then flips bits in those last five
bytes to make the hash match.  Chances are good that calling
obfuscate_name() twice on the same name will return different results,
which means that symlink targets won't point anywhere useful after the
obfuscation.

One could make metadump remember the (input -> output) pairs instead of
regenerating the names every time, but this comes at a cost of higher
memory consumption.  I actually did this for parent pointers so that
obfuscated dumped pptrs are still verifiable by xfs_repair.

However, symlink targets aren't required to point to a valid path, so
there doesn't seem to be much reason to add that overhead.

--D

> -Eric

  reply	other threads:[~2023-06-05 17:09 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-05 15:36 [PATCHSET v3 0/5] xfsprogs: fix ascii-ci problems, then kill it Darrick J. Wong
2023-06-05 15:36 ` [PATCH 1/5] libxfs: test the ascii case-insensitive hash Darrick J. Wong
2023-06-05 16:30   ` Eric Sandeen
2023-06-14  7:44   ` Carlos Maiolino
2023-06-05 15:36 ` [PATCH 2/5] xfs_db: move obfuscate_name assertion to callers Darrick J. Wong
2023-06-05 15:36 ` [PATCH 3/5] xfs_db: fix metadump name obfuscation for ascii-ci filesystems Darrick J. Wong
2023-06-05 16:59   ` Eric Sandeen
2023-06-05 17:09     ` Darrick J. Wong [this message]
2023-06-05 17:18       ` Eric Sandeen
2023-06-05 17:19   ` Eric Sandeen
2023-06-14 11:10   ` Carlos Maiolino
2023-06-15 16:11   ` [PATCH v2 " Darrick J. Wong
2023-06-22 11:45     ` Carlos Maiolino
2023-06-05 15:36 ` [PATCH 4/5] mkfs.xfs.8: warn about the version=ci feature Darrick J. Wong
2023-06-05 15:36 ` [PATCH 5/5] mkfs: deprecate the ascii-ci feature Darrick J. Wong

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=20230605170948.GL72241@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=cem@kernel.org \
    --cc=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox