Re: NFS4 crack

[Christoph Hellwig <hch@lst.de>]

On Sun, Sep 18, 2005 at 10:36:15AM -0400, J. Bruce Fields wrote:
> On Sun, Sep 18, 2005 at 12:21:00PM +0200, Christoph Hellwig wrote:
> > I've recently turned on NFS4 server support accidentally, just to get
> > error messages like:
> > 
> > "NFSD: recovery directory /var/lib/nfs/v4recovery doesn't exist"
> > 
> > To my horror I found out that this comes from kernel code, which messes
> > with a hardcoded directory, completelyu ingoring any namespace or other
> > uses issues.
> 
> As long as all nfsd threads are in the same namespace, I don't see any
> namespace issues.  What am I missing?

Namespaces issues above was meant as kernel can't assume namespace at
all, not even thinking about multiple namespaces which makes it even
more wrong.  Who sais I allow the kernel to mess with
/var/lib/nfs/v4recover?  Who tells any userspace process is even in the
same namespace as the nfs threads to create the directories?

Kernel assuming any namespace is wrong and we don't do it anywhere.
> 
> > The fs handling in fs/nfs/nfs4recovery.c is rather broken in addition.
> 
> For example?

 - opens a directory O_RDWR which open_namei wouldn't even allow
 - tries to build dentry list from vfs_readdir callback, leading to
   deadlocks on filesystems that take the same lock from readdir
   and lookup
 - resets fsuid/fsgids without checks, synchronization or callouts
   into subsystems that care (security, keys, ptrace)
 - looks up /var/lib/nfs/v4recovery without ensuring it's a directory
 
and probably a few more if one tried to look at it for more than five
minutes.  This is code that could be a third of the size if written
in userpsace and actually had a chance to be correct there, nevermind
the policy violations.

Please remove the code and never ever try to sneak in something like
that again.  Thanks.