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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 11 Nov 2009 17:26:10 +0900 From: Trond Myklebust <trond.myklebust@....uio.no> To: Miklos Szeredi <miklos@...redi.hu> Cc: Jeff Layton <jlayton@...hat.com>, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, linux-nfs@...r.kernel.org, ebiederm@...ssion.com, adobriyan@...il.com, viro@...IV.linux.org.uk, jamie@...reable.org Subject: Re: [PATCH 0/2] vfs: ensure that dentries are revalidated on open (try #2) On Wed, 2009-11-11 at 08:57 +0100, Miklos Szeredi wrote: > On Tue, 10 Nov 2009, Jeff Layton wrote: > > This is the second attempt to fix this problem. The first one attempted > > to fix this in procfs, but Eric Biederman pointed out that file bind > > mounts have a similar problem. This set attempts to fix the issue at a > > higher level, in the generic VFS layer. > > I suspect the correct fix would be to clean up the open API so that > NFSv4 doesn't have to hack its stateful open routine into the > ->lookup() and ->d_revalidate() methods. I've been working on that. I hope to have patches soon... > Having said that, doing revalidation for proc symlinks and bind mounts > (and not just for opens) might make sense. This is something similar > to FS_REVAL_DOT, so perhaps make it conditional on this flag (or a > new, appropriately named one). Aren't both proc symlinks and bind mounts pretty much guaranteed to point to a valid dentry? Once we fix the open case, I can't see that we need to do much more. Networked filesystems may want to revalidate the inode attributes, but not the dentry itself... Cheers Trond -- 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/
Powered by blists - more mailing lists