'noacl' NFS parameter seems ineffective (Fedora Core 7)

'noacl' NFS parameter seems ineffective (Fedora Core 7)

[Myles Uyema]

[-- Attachment #1.1: Type: text/plain, Size: 672 bytes --]

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.

[-- Attachment #1.2: Type: text/html, Size: 854 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7)

[Peter Staubach]

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

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

Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7)

[Myles Uyema]

[-- Attachment #1.1: Type: text/plain, Size: 1483 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 2086 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7)

[Peter Staubach]

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

Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7)

[Trond Myklebust]

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

Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7)

[Peter Staubach]

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

Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7)

[Trond Myklebust]

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

Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7)

[Clay McClure]

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

Re: 'noacl' NFS parameter seems ineffective (Fedora Core 7)

[Trond Myklebust]

On Mon, 2008-05-05 at 18:27 +0000, Clay McClure wrote:
> 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?

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