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
next prev parent 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