From: Clay McClure <clay-zo/yENU/GurR7s880joybQ@public.gmane.org>
Subject: Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7)
Date: Mon, 5 May 2008 18:27:02 +0000 (UTC)
Message-ID: <loom.20080505T174704-239@post.gmane.org>
References: <a90f74cc0707051401p38167340s955be299a807710d@mail.gmail.com> <468D6064.3080307@redhat.com> <1183728245.6463.17.camel@heimdal.trondhjem.org> <468E4659.8090209@redhat.com> <1183732066.6463.44.camel@heimdal.trondhjem.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: linux-nfs@vger.kernel.org
Return-path: <linux-nfs-owner@vger.kernel.org>
Received: from main.gmane.org ([80.91.229.2]:53300 "EHLO ciao.gmane.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1760718AbYEES1S (ORCPT <rfc822;linux-nfs@vger.kernel.org>);
	Mon, 5 May 2008 14:27:18 -0400
Received: from list by ciao.gmane.org with local (Exim 4.43)
	id 1Jt5P8-0003af-CE
	for linux-nfs@vger.kernel.org; Mon, 05 May 2008 18:27:14 +0000
Received: from 208.82.18.93 ([208.82.18.93])
        by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <linux-nfs@vger.kernel.org>; Mon, 05 May 2008 18:27:14 +0000
Received: from clay by 208.82.18.93 with local (Gmexim 0.1 (Debian))
        id 1AlnuQ-0007hv-00
        for <linux-nfs@vger.kernel.org>; Mon, 05 May 2008 18:27:14 +0000
Sender: linux-nfs-owner@vger.kernel.org
List-ID: <linux-nfs.vger.kernel.org>

Trond Myklebust <trond.myklebust <at> fys.uio.no> writes:

> On Fri, 2007-07-06 at 09:40 -0400, Peter Staubach wrote:
> > It was misguided on someone's part to think that no ACLs meant that
> > checking the mode bits for permissions was sufficient.
> 
> Yup.

It seems to me that disabling ACCESS might prevent clients from knowing
whether an operation is allowed, but it would not allow clients to bypass
server ACLs. From a security perspective, then, I would think disabling
ACCESS would not affect the correctness of the protocol.

In other words, if a client with ACCESS disabled determined (by mode
bits alone) that a read operation was allowed, and issued a READ call,
would the server still determine whether the request was allowed
(according to its ACL and user mapping policy), and return
NFS3ERR_ACCES if not?

> The correct way to deal with the problem of too many ACCESS calls
> was rather to improve the caching. There should be a vast difference
> between a 2.6.19 kernel or higher and earlier versions when it comes to
> the ability to cache credentials from multiple users and I hope that
> addresses the problems that people were seeing.

ACCESS calls make up 17% of the NFS ops generated by our application
running on a stock CentOS 5 2.6.18 kernel. We don't use ACLs or root
mapping. One user (root) performs all file access on the NFS volume
in question.

Would the credential caching you mention in 2.6.19 help us reduce the
number of ACCESS operations we see (even though only one user is
performing file I/O)?

Is it safe to apply a patch to eliminate ACCESS altogether?

Thanks,

Clay