From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Myles Uyema" Subject: 'noacl' NFS parameter seems ineffective (Fedora Core 7) Date: Thu, 5 Jul 2007 14:01:28 -0700 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1544609742==" To: nfs@lists.sourceforge.net Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1I6YSA-0006kv-5a for nfs@lists.sourceforge.net; Thu, 05 Jul 2007 14:01:30 -0700 Received: from ug-out-1314.google.com ([66.249.92.173]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1I6YSB-0006NB-Kw for nfs@lists.sourceforge.net; Thu, 05 Jul 2007 14:01:33 -0700 Received: by ug-out-1314.google.com with SMTP id m2so594219uge for ; Thu, 05 Jul 2007 14:01:29 -0700 (PDT) List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net --===============1544609742== Content-Type: multipart/alternative; boundary="----=_Part_136635_8844159.1183669288319" ------=_Part_136635_8844159.1183669288319 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline If I understand the explanation of the 'noacl' parameter, it should prevent ACCESS calls right? I'm not seeing this occurring on Fedora Core 7 ( 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 14:56:37 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux) I mounted using tcp,noacl,rsize=32768,wsize=32768. The NFS server is a NetApp filer running 7.2.1.1, and is a unix-only filesystem. Then I ran a script to 'dd' 286 files on the NFS mountpoint. The script ran as UID 48. 340 reads 286 getattr 286 access The nfsstat showed my client still performing ACCESS calls. I'd like to believe that the GETATTR has already verified the permission bits, and thus an ACCESS shouldn't be necessary. ------=_Part_136635_8844159.1183669288319 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline If I understand the explanation of the 'noacl' parameter, it should prevent ACCESS calls right?  I'm not seeing this occurring on Fedora Core 7 (2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 14:56:37 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux)

I mounted using tcp,noacl,rsize=32768,wsize=32768.  The NFS server is a NetApp filer running 7.2.1.1, and is a unix-only filesystem.

Then I ran a script to 'dd' 286 files on the NFS mountpoint.  The script ran as UID 48.
340 reads
286 getattr
286 access

The nfsstat showed my client still performing ACCESS calls.  I'd like to believe that the GETATTR has already verified the permission bits, and thus an ACCESS shouldn't be necessary.
------=_Part_136635_8844159.1183669288319-- --===============1544609742== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ --===============1544609742== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs --===============1544609742==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Staubach Subject: Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7) Date: Thu, 05 Jul 2007 17:19:32 -0400 Message-ID: <468D6064.3080307@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: nfs@lists.sourceforge.net To: Myles Uyema Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1I6Yjh-00008v-1x for nfs@lists.sourceforge.net; Thu, 05 Jul 2007 14:19:37 -0700 Received: from mx1.redhat.com ([66.187.233.31]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1I6Yjk-0007HJ-CS for nfs@lists.sourceforge.net; Thu, 05 Jul 2007 14:19:40 -0700 In-Reply-To: List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net Myles Uyema wrote: > If I understand the explanation of the 'noacl' parameter, it should > prevent ACCESS calls right? I'm not seeing this occurring on Fedora > Core 7 (2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 14:56:37 EDT 2007 x86_64 > x86_64 x86_64 GNU/Linux) > > I mounted using tcp,noacl,rsize=32768,wsize=32768. The NFS server is > a NetApp filer running 7.2.1.1 , and is a unix-only > filesystem. > > Then I ran a script to 'dd' 286 files on the NFS mountpoint. The > script ran as UID 48. > 340 reads > 286 getattr > 286 access > > The nfsstat showed my client still performing ACCESS calls. I'd like > to believe that the GETATTR has already verified the permission bits, > and thus an ACCESS shouldn't be necessary. Actually, all that the "noacl" mount option means is to not attempt to get or set or ACLs on the server. It does not affect the security checking that the client does to verify access. The permission bits are not enough to determine access permissions. Root mapping on the server is an easy example of this. Therefore, the client always goes over the wire to query the server for the permissions that it will allow. Thanx... ps ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Myles Uyema" Subject: Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7) Date: Thu, 5 Jul 2007 14:39:34 -0700 Message-ID: References: <468D6064.3080307@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0445328718==" Cc: nfs@lists.sourceforge.net To: "Peter Staubach" Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1I6Z31-0002HV-7k for nfs@lists.sourceforge.net; Thu, 05 Jul 2007 14:39:35 -0700 Received: from ug-out-1314.google.com ([66.249.92.168]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1I6Z32-0003l4-Ko for nfs@lists.sourceforge.net; Thu, 05 Jul 2007 14:39:38 -0700 Received: by ug-out-1314.google.com with SMTP id m2so602883uge for ; Thu, 05 Jul 2007 14:39:35 -0700 (PDT) In-Reply-To: <468D6064.3080307@redhat.com> List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net --===============0445328718== Content-Type: multipart/alternative; boundary="----=_Part_137195_3740438.1183671574802" ------=_Part_137195_3740438.1183671574802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for the clarification. I don't suppose there's an option to do what I've described? Rather - assume that there is no acl, no uid mapping/translation on the server side? On 7/5/07, Peter Staubach wrote: > > Myles Uyema wrote: > > If I understand the explanation of the 'noacl' parameter, it should > > prevent ACCESS calls right? I'm not seeing this occurring on Fedora > > Core 7 (2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 14:56:37 EDT 2007 x86_64 > > x86_64 x86_64 GNU/Linux) > > > > I mounted using tcp,noacl,rsize=32768,wsize=32768. The NFS server is > > a NetApp filer running 7.2.1.1 , and is a unix-only > > filesystem. > > > > Then I ran a script to 'dd' 286 files on the NFS mountpoint. The > > script ran as UID 48. > > 340 reads > > 286 getattr > > 286 access > > > > The nfsstat showed my client still performing ACCESS calls. I'd like > > to believe that the GETATTR has already verified the permission bits, > > and thus an ACCESS shouldn't be necessary. > > Actually, all that the "noacl" mount option means is to not attempt > to get or set or ACLs on the server. It does not affect the security > checking that the client does to verify access. > > The permission bits are not enough to determine access permissions. > Root mapping on the server is an easy example of this. Therefore, > the client always goes over the wire to query the server for the > permissions that it will allow. > > Thanx... > > ps > ------=_Part_137195_3740438.1183671574802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks for the clarification.  I don't suppose there's an option to do what I've described?  Rather - assume that there is no acl, no uid mapping/translation on the server side?

On 7/5/07, Peter Staubach <staubach@redhat.com> wrote:
Myles Uyema wrote:
> If I understand the explanation of the 'noacl' parameter, it should
> prevent ACCESS calls right?  I'm not seeing this occurring on Fedora
> Core 7 (2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 14:56:37 EDT 2007 x86_64
> x86_64 x86_64 GNU/Linux)
>
> I mounted using tcp,noacl,rsize=32768,wsize=32768.  The NFS server is
> a NetApp filer running 7.2.1.1 <http://7.2.1.1 >, and is a unix-only
> filesystem.
>
> Then I ran a script to 'dd' 286 files on the NFS mountpoint.  The
> script ran as UID 48.
> 340 reads
> 286 getattr
> 286 access
>
> The nfsstat showed my client still performing ACCESS calls.  I'd like
> to believe that the GETATTR has already verified the permission bits,
> and thus an ACCESS shouldn't be necessary.

Actually, all that the "noacl" mount option means is to not attempt
to get or set or ACLs on the server.  It does not affect the security
checking that the client does to verify access.

The permission bits are not enough to determine access permissions.
Root mapping on the server is an easy example of this.  Therefore,
the client always goes over the wire to query the server for the
permissions that it will allow.

    Thanx...

       ps

------=_Part_137195_3740438.1183671574802-- --===============0445328718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ --===============0445328718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs --===============0445328718==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Staubach Subject: Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7) Date: Fri, 06 Jul 2007 07:46:11 -0400 Message-ID: <468E2B83.70908@redhat.com> References: <468D6064.3080307@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: nfs@lists.sourceforge.net To: Myles Uyema Return-path: Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1I6mGP-0000n6-KV for nfs@lists.sourceforge.net; Fri, 06 Jul 2007 04:46:17 -0700 Received: from mx1.redhat.com ([66.187.233.31]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1I6mGT-0002Ut-1G for nfs@lists.sourceforge.net; Fri, 06 Jul 2007 04:46:21 -0700 In-Reply-To: List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net Myles Uyema wrote: > Thanks for the clarification. I don't suppose there's an option to do > what I've described? Rather - assume that there is no acl, no uid > mapping/translation on the server side? Yes, but there are other ramifications of it. It is "nfsvers=2" and you'll be limited to 8K reads and writes... ps ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7) Date: Fri, 06 Jul 2007 09:24:05 -0400 Message-ID: <1183728245.6463.17.camel@heimdal.trondhjem.org> References: <468D6064.3080307@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: nfs@lists.sourceforge.net To: Peter Staubach Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1I6nnC-00049b-AQ for nfs@lists.sourceforge.net; Fri, 06 Jul 2007 06:24:16 -0700 Received: from pat.uio.no ([129.240.10.15] ident=[U2FsdGVkX18eEarJIKMQ723oRzl3edmCaBC8IGFVh+s=]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1I6nnE-0005q1-Hi for nfs@lists.sourceforge.net; Fri, 06 Jul 2007 06:24:17 -0700 In-Reply-To: <468D6064.3080307@redhat.com> List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net On Thu, 2007-07-05 at 17:19 -0400, Peter Staubach wrote: > Actually, all that the "noacl" mount option means is to not attempt > to get or set or ACLs on the server. It does not affect the security > checking that the client does to verify access. > > The permission bits are not enough to determine access permissions. > Root mapping on the server is an easy example of this. Therefore, > the client always goes over the wire to query the server for the > permissions that it will allow. Right. The confusion here stems from the fact that SuSE attempted to make "noacl" mean both "I will not get/set any posix acls" and "there are no acls on the server" in their kernels. The common practice of root mapping blows that argument right out of the water, and so I never applied the parts of their ACL patches that switch off ACCESS calls. Trond ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Staubach Subject: Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7) Date: Fri, 06 Jul 2007 09:40:41 -0400 Message-ID: <468E4659.8090209@redhat.com> References: <468D6064.3080307@redhat.com> <1183728245.6463.17.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: nfs@lists.sourceforge.net To: Trond Myklebust Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1I6o3G-00065l-BL for nfs@lists.sourceforge.net; Fri, 06 Jul 2007 06:40:51 -0700 Received: from mx1.redhat.com ([66.187.233.31]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1I6o3I-0004Az-NE for nfs@lists.sourceforge.net; Fri, 06 Jul 2007 06:40:54 -0700 In-Reply-To: <1183728245.6463.17.camel@heimdal.trondhjem.org> List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net Trond Myklebust wrote: > On Thu, 2007-07-05 at 17:19 -0400, Peter Staubach wrote: > >> Actually, all that the "noacl" mount option means is to not attempt >> to get or set or ACLs on the server. It does not affect the security >> checking that the client does to verify access. >> >> The permission bits are not enough to determine access permissions. >> Root mapping on the server is an easy example of this. Therefore, >> the client always goes over the wire to query the server for the >> permissions that it will allow. >> > > Right. The confusion here stems from the fact that SuSE attempted to > make "noacl" mean both "I will not get/set any posix acls" and "there > are no acls on the server" in their kernels. > > The common practice of root mapping blows that argument right out of the > water, and so I never applied the parts of their ACL patches that switch > off ACCESS calls. Yes, I think that RHEL-4 had that bug too, at least for a while. (I hope only for a while... :-) ) It was misguided on someone's part to think that no ACLs meant that checking the mode bits for permissions was sufficient. Thanx... ps ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7) Date: Fri, 06 Jul 2007 10:27:46 -0400 Message-ID: <1183732066.6463.44.camel@heimdal.trondhjem.org> References: <468D6064.3080307@redhat.com> <1183728245.6463.17.camel@heimdal.trondhjem.org> <468E4659.8090209@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: nfs@lists.sourceforge.net To: Peter Staubach Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1I6omj-0003Cl-33 for nfs@lists.sourceforge.net; Fri, 06 Jul 2007 07:27:49 -0700 Received: from pat.uio.no ([129.240.10.15] ident=[U2FsdGVkX19dXEz4fbRW4txE9an8eJvLVLhGIOt5igc=]) by mail.sourceforge.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.44) id 1I6omm-0006Kw-5k for nfs@lists.sourceforge.net; Fri, 06 Jul 2007 07:27:52 -0700 In-Reply-To: <468E4659.8090209@redhat.com> List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net 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. 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. Trond ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Clay McClure Subject: Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7) Date: Mon, 5 May 2008 18:27:02 +0000 (UTC) Message-ID: References: <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: 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 ); 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 ; 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 ; Mon, 05 May 2008 18:27:14 +0000 Sender: linux-nfs-owner@vger.kernel.org List-ID: Trond Myklebust 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Trond Myklebust Subject: Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7) Date: Mon, 05 May 2008 16:29:37 -0400 Message-ID: <1210019377.7448.12.camel@localhost> References: <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 Cc: linux-nfs@vger.kernel.org To: Clay McClure Return-path: Received: from pat.uio.no ([129.240.10.15]:38221 "EHLO pat.uio.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757228AbYEEU3l (ORCPT ); Mon, 5 May 2008 16:29:41 -0400 In-Reply-To: Sender: linux-nfs-owner@vger.kernel.org List-ID: On Mon, 2008-05-05 at 18:27 +0000, Clay McClure wrote: > Trond Myklebust 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? Yes, but that was never the problem. The problem is that clients can and do cache data, and need to know who is allowed to access that data. > > 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)? Since CentOS 5 is a copy of RHEL-5, I would expect it to already have the patch applied. > Is it safe to apply a patch to eliminate ACCESS altogether? In general? No (see above). That said, you can always find corner cases with peculiar environments. Perhaps in your particular environment where there is only one user, removing access is safe and will actually produce a win, as opposed to generating yet more GETATTR calls in order to revalidate the cached modebit data. It all depends on the underlying reason for why you are seeing such a high number of ACCESS calls. Trond