From: Eric Sandeen <sandeen@redhat.com>
To: xfs-oss <xfs@oss.sgi.com>
Subject: [PATCH] metadump: obfuscate symlinks by path component
Date: Mon, 09 Apr 2012 23:34:12 -0500 [thread overview]
Message-ID: <4F83B844.3060508@redhat.com> (raw)
xfs_metadump currently obfuscates entire symlinks without regard
to path components; this can lead to a corrupt image when restoring
a metadump containing extremely long symlinks:
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
component of symlink in inode 145 too long
problem with symbolic link in inode 145
cleared inode 145
... <more trail of woe>
Fix this by consolidating symlink obfuscation into a new
function which obfuscates one path component at a time.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
Yes, I need to do an xfstest for this. metadumping a filesystem
after fsstressing it works well.
diff --git a/db/metadump.c b/db/metadump.c
index c5ffddb..9f15d9e 100644
--- a/db/metadump.c
+++ b/db/metadump.c
@@ -956,6 +956,40 @@ obfuscate_sf_dir(
}
static void
+obfuscate_path_components(
+ char *buf,
+ __uint64_t len)
+{
+ uchar_t *comp;
+ xfs_dahash_t hash;
+
+ comp = (uchar_t *)buf;
+ while (comp < (uchar_t *)buf + len) {
+ char *slash;
+ int namelen;
+
+ /* find slash at end of this component */
+ slash = strchr((char *)comp, '/');
+ if (!slash) {
+ /* last (or single) component */
+ namelen = strlen((char *)comp);
+ hash = libxfs_da_hashname(comp, namelen);
+ obfuscate_name(hash, namelen, comp);
+ break;
+ }
+ namelen = slash - (char *)comp;
+ /* handle leading or consecutive slashes */
+ if (!namelen) {
+ comp++;
+ continue;
+ }
+ hash = libxfs_da_hashname(comp, namelen);
+ obfuscate_name(hash, namelen, comp);
+ comp += namelen + 1;
+ }
+}
+
+static void
obfuscate_sf_symlink(
xfs_dinode_t *dip)
{
@@ -971,8 +1005,7 @@ obfuscate_sf_symlink(
}
buf = (char *)XFS_DFORK_DPTR(dip);
- while (len > 0)
- buf[--len] = random() % 127 + 1;
+ obfuscate_path_components(buf, len);
}
static void
@@ -1176,11 +1209,8 @@ obfuscate_symlink_blocks(
char *block,
xfs_dfilblks_t count)
{
- int i;
-
count <<= mp->m_sb.sb_blocklog;
- for (i = 0; i < count; i++)
- block[i] = random() % 127 + 1;
+ obfuscate_path_components(block, count);
}
#define MAX_REMOTE_VALS 4095
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
reply other threads:[~2012-04-10 4:34 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=4F83B844.3060508@redhat.com \
--to=sandeen@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox