Re: NFS4 crack

[Greg Banks <gnb@sgi.com>]

On Thu, Sep 22, 2005 at 02:07:36PM -0400, Peter Staubach wrote:
> Trond Myklebust wrote:
> 
> >to den 22.09.2005 Klokka 13:38 (-0400) skreiv Peter Staubach:
> >
> >Sure, but open alone isn't sufficient. A lot (most?) of the operations
> >involving filehandles are acting on directories.
> >
> >Imagine if someone renames a directory on the server while the NFS
> >server is in the middle of an unlink() operation, for instance.
> 
> Yup, although you could resolve that by introducing a whole set of
> operations which work off of file descriptors, instead of pathnames.

To see why this is a bad idea, google for the unforeseen security
implications of Solaris' fchroot() syscall.  Adding this kind of
syscall is *not* cost-free, you just won't know the cost until it's
too late to fix.

> [...] there are performance issues as well.

Performance sells boxes, selling boxes pays my bills, that's enough
reason for me.  The ability to do zero-copy efficiently and to
(eventually) support RDMA into the page cache is enough reason for
a kernel nfsd.  Sendfile?  don't make me laugh.

Also, a kernel nfsd can see network packet boundaries and other
information not visible through any existing network API, and it does
so in nonblocking fashion, which enables it to bounds check RPC calls
better than any userspace RPC implementation can.  This is one reason
why (e.g.) TCP XDR fragment header DoS attacks are much harder against
a kernel based server than a userspace server.  Another reason is
that the kernel nfsd refuses to accept multiple-fragment RPC calls,
which is impossible if you use the libc RPC server library.

Userspace nfsd: just say no.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.