linux-kernel - Re: [take 3] pohmelfs: call for inclusion

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 21 Mar 2012 21:18:35 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Evgeniy Polyakov <zbr@...emap.net>, Joe Perches <joe@...ches.com>,
	greg@...ah.com, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, linux-fsdevel@...r.kernel.org,
	Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [take 3] pohmelfs: call for inclusion

On Wed, Mar 21, 2012 at 02:02:43PM -0700, Linus Torvalds wrote:

> I can't really say that I tend to care deeply about the innards of
> some unusual filesystem that hopefully cannot possibly impact anything
> else. So as long as you keep people like Al happy (or at least not
> overly unhappy), I'm unlikely to worry too much.

As far as I can see, it's still suffering the same problems it used to;
in particular, the games it plays with d_path() are completely bogus.
Take a look at this:

static int pohmelfs_construct_path_string(struct pohmelfs_inode *pi, void *data
 int len)
{
	struct path path;
	struct dentry *d;
	char *ptr;
	int err = 0, strlen, reduce = 0;

	d = d_find_alias(&pi->vfs_inode);
	if (!d) {
		err = -ENOENT;
		goto err_out_exit;
	}

	spin_lock(&current->fs->lock);
	path.mnt = mntget(current->fs->root.mnt);
	spin_unlock(&current->fs->lock);

	path.dentry = d;

	if (!IS_ROOT(d) && d_unhashed(d))
		reduce = 1;

	ptr = d_path(&path, data, len);
	if (IS_ERR(ptr)) {
		err = PTR_ERR(ptr);
		goto err_out_put;
	}

	if (reduce && len >= UNHASHED_OBSCURE_STRING_SIZE) {
		char *end = data + len - UNHASHED_OBSCURE_STRING_SIZE;
		*end = '\0';
	}

	strlen = len - (ptr - (char *)data);
	memmove(data, ptr, strlen);
	ptr = data;

	err = strlen - 1; /* no including 0-byte */

	pr_debug("%s: dname: '%s', len: %u, maxlen: %u, name: '%s', strlen: %d.\n",
		__func__, d->d_name.name, d->d_name.len, len, ptr, strlen);

err_out_put:
	dput(d);
	mntput(path.mnt);
err_out_exit:
	return err;
}

For Nth time: what happens to poor sod that happens to be chrooted
into that animal?  We get pathname relative to process' root or to fs
root, whichever's closer.  And no, it's used not just for debugging 
printks...

I think I've asked that question at least 3 times.  Never got anything
resembling an answer...  Is that misspelled dentry_path()?  Or is something
subtle going on and we really want different strings generated for
chrooted processes here?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/