Re: NFS4 crack

["J. Bruce Fields" <bfields@fieldses.org>]

On Mon, Sep 19, 2005 at 12:35:47PM +0200, Christoph Hellwig wrote:
> 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?

It's run-time configurable if you don't like the default.

> Who tells any userspace process is even in the same namespace as the
> nfs threads to create the directories?

No userspace process is likely to care, except maybe for debugging
purposes.  This isn't a userspace<->kernel interface, it's just a way to
store some information on disk so nfsd can find it again on next boot.

> Kernel assuming any namespace is wrong and we don't do it anywhere.

Well, nfsd does have some assumptions--mountd, exportfs, and nfsd all
have to be in the same namespace, for example.  (Or at least namespaces
that are identical on exported paths.)

> > > 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.

Are you sure about readdir?  It looks to me like nfsd has done lookups
there for some time--see, e.g., fs/nfsd/nfs3xdr.c:compose_entry_fh().

But I'll read through it again and check the other stuff you mention,
thanks.

--b.