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.
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 <[email protected]> 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
>
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs