linux-kernel - Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks

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]

Message-ID: <20150516054626.GS7232@ZenIV.linux.org.uk>
Date:	Sat, 16 May 2015 06:46:26 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	NeilBrown <neilb@...e.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andreas Dilger <adilger@...ger.ca>,
	Dave Chinner <david@...morbit.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU
 symlinks

On Sat, May 16, 2015 at 02:45:27PM +1000, NeilBrown wrote:

> Yes, I've looked lately :-)
> I think that all of RCU-walk, and probably some of REF-walk should happen
> before the filesystem gets to see anything.
> But once you hit a non-positive dentry or the parent of the target name, I'd
> rather hand over the the FS.

... and be ready to get it back when the sucker runs into a symlink.  Unless
you want to handle _those_ in NFS somehow (including an absolute one starting
with /sys/, etc.).

> NFSv4 has the ability to look up multiple components in a single LOOKUP call.
> VFS doesn't give it a chance to try because it wants to go step-by-step, and
> wants each entry in the cache to have an inode etc.

Do tell, how do we deal with .. afterwards if we leave the intermediate ones
without inodes?  We _could_ feed multi-component requests to filesystems
(and NFSv4 isn't the first one to handle that - 9p had been there a lot
earlier), but then you get to
	* populate all of them with inodes
	* be damn careful to avoid multiple dentries for the same directory
inode
Look, creating those suckers isn't the worst part; you need to be ready for
e.g. mount(2) or pathname resolution playing with the ones you'd created.
It's not fs-private data structure; pathname resolution might very well span
many filesystem types.

Worse, you get to deal with several multi-component requests jumping into
fs at the same place.  With responses arriving a bit afterwards, and guess
what?  Those requests happen to share bits and pieces of prefixes.  Oh,
and one of them is a rename.  Dealing with just the final components isn't
a problem; you'll need to deal with directory tree in all its fscking glory.
In a way that wouldn't be in too incestous relationship with the pathwalking
logics in VFS and, by that proxy, such in all other fs types.

In particular, "unknown" for intermediate nodes is a recipe for really
nasty mess.  If the path can rejoin the known universe several components
later... <shudder>

Dealing with multi-component lookups isn't impossible and might be a good
idea, but only if all intermediates are populated.  What information does
NFSv4 multi-component lookup give you?  9p one gives an array of FIDs,
one per component, and that is best used as multi-component revalidate
on hot dcache...
--
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/