Subject: Re: ACL in NFSv4 protocol

From: Mike Eisler <[email-masked]>
Date: Thu, 6 Mar 2003 11:05:37 -0800 (PST)

> From: "Eric Sedlar" <[email-masked]>
> To: "Nicolas Williams" <[email-masked]>
> Cc: "Sergey Klyushin" <[email-masked]>,
>    "'Mike Eisler'" <[email-masked]>, <[email-masked]>
> Subject: Re: ACL in NFSv4 protocol

> Seems like it defeats most of the purpose of caching if you have to do a

I believe the primary benefits of delegation-based caching are in
caching of data, and byte range locks, not in delegating
access rights.

> server
> round trip before every NFS operation requiring an access check just to
> check
> for access control.  Wouldn't it be better to find a way to ensure that the
> client
> can evaluate the ACL itself?

From the specification (the context is delegations):

   The server may return an nfsace4 that is more restrictive than the
   actual ACL of the file.  This includes an nfsace4 that specifies
   denial of all access.  Note that some common practices such as
   mapping the traditional user "root" to the user "nobody" may make it
   incorrect to return the actual ACL of the file in the delegation
   response.

The ACL is only advisory in nature, just as UNIX mode was only advisory
in NFSv2.

> > > Isn't it the case that whatever implementation choices the server makes
> as
> > > far as implementing ACLs, they must be disclosed to the client via a
> flag,

What flag is this? It could be in specification, but I can't recall it
or find it.

	-mre

---

From: "Eric Sedlar" <[email-masked]>
Date: Thu, 6 Mar 2003 11:17:17 -0800

> caching of data, and byte range locks, not in delegating

If you are dealing with larger files, I'm sure you're correct, but for small
files, eliminating the access check would be more useful.

I'm just pointing out a potential performance optimization available--it
might
not be feasible to achieve in an interoperable environment.  Just seems like
the WG is very concerned about performance, so I thought I'd point this
area out.