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...? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
