Re: races in ll_splice_alias() and elsewhere (ext4, ocfs2)

[Al Viro <viro@ZenIV.linux.org.uk>]

On Thu, Mar 10, 2016 at 06:55:43PM -0500, Theodore Ts'o wrote:

> The ext4_d_revalidate() function was an attempt to square the circle,
> but yes, I've been coming to the conclusion that it doesn't work all
> that well.  One thing I've been considering is to make access to the
> keys a global property.  So the first time a user with access to the
> key tries to access an encrypted file, we import the key into mounted
> file system's ext4_sb_info structure, and we bump a generation
> counter, and then ext4_d_revalidate() simply returns "invalid" for all
> denrty entries which (a) refer to an encrypted file or directory, and
> (b) whose generation number is less than the current generation
> number.

That sounds rather DoSable, if I'm not misparsing you...

> Similarly, if we invalidate a key, we remove the key from tthe keyring
> hanging off of the mounted file system's sb_info structure, and then
> bump the generation number, which will invalidate the dentries for all
> encrypted files/directories on that file system.
> 
> This is a bit non-optimal, but I don't see any other way of solving
> the problem.  Al, do you have any suggestions?

In any case, the current variant needs at least dget_parent()/dput() - blind
access of ->d_parent is simply broken.  As for using ->d_revalidate() for
that stuff...  I'm not sure.  How should those directories look like for
somebody who doesn't have a key?  Should e.g. getdents(2) results depend on
who's calling it, or who'd opened the directory, or...?