From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Banks Subject: Re: NFS4 crack Date: Fri, 23 Sep 2005 08:50:35 +1000 Message-ID: <20050922225035.GA9165@sgi.com> References: <1127407973.8365.26.camel@lade.trondhjem.org> <4332EC26.9010307@redhat.com> <1127411552.8365.41.camel@lade.trondhjem.org> <4332F2E8.8030107@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Trond Myklebust , Bryan Henderson , Neil Brown , akpm@osdl.org, andros@citi.umich.edu, bfields@citi.umich.edu, Christoph Hellwig , linux-fsdevel@vger.kernel.org, Olaf Kirch Return-path: Received: from omx3-ext.sgi.com ([192.48.171.20]:26850 "EHLO omx3.sgi.com") by vger.kernel.org with ESMTP id S1751286AbVIVWvf (ORCPT ); Thu, 22 Sep 2005 18:51:35 -0400 To: Peter Staubach Content-Disposition: inline In-Reply-To: <4332F2E8.8030107@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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.