Subject: Re: [nfsv4] re: ACL and Posix Mode bit interaction

From: [email-masked]
Date: Fri, 28 Jul 2006 14:10:51 -0400 (EDT)

>   I believe you mean "no ACL" use the mode-bits.
Yes, I meant "no ACL". The problem is "How does a server express no ACL"?
(I suggested "empty ACL" -> "no ACL", but agree that isn't ideal.)

> Rick seems to think there is no such thing as "no acl."  I'm not convinced:
> 
>    The server must return an error
>    if it supports an attribute but cannot obtain its value.  In that
>    case no attribute values will be returned.

Jim is correct that I had assumed that a Getattr Op must return an ACL, if
requested and the server supports ACLs. (It also seemed that Andreas and Bruce
read it that way, from the recent thread.) Now that I've read para 2 of
DESCRIPTION in sec. 14.2.7 again, I'm not so sure.

   The server must return a value for each attribute that the client
   requests if the attribute is supported by the server.  If the server
   does not support an attribute or cannot approximate a useful value
   then it must not return the attribute value and must not set the
   attribute bit in the result bitmap.  The server must return an error
   if it supports an attribute but cannot obtain its value.  In that
   case no attribute values will be returned.

The second sentence seems to contradict the first for the case "cannot
approximate a useful value", which is exactly what I'd call the "no ACL"
case. Then the third/fourth sentences seems to contradict the second, saying it
must return an error instead of the bitmap with the bit not set?

If you believe that the server must return an ACL, then your choices seem
to be:
- return an empty ACL for "no ACL"
OR
- generate a fake one, which then leads to the POSIX Mode->ACL mapping
  exercise that just never seems to get settled.

But, yes I meant "no ACL" and, for want of a better way to express it,
selected "empty ACL" -> "no ACL".

rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 28 Jul 2006 15:15:26 -0400

On Fri, Jul 28, 2006 at 02:10:51PM -0400, [email-masked] wrote:
> If you believe that the server must return an ACL,

I guess the question is what current clients will do if your server
doesn't return an ACL after having claimed ACL support.  It looks to me
like they could legally just return an error to the user when the ACL is
requested.  Maybe that's OK with you?

> then your choices seem to be:

The reason you want "no ACL" is to implement the
first-check-the-ACL-then-fallback-on-mode semantics.  Those semantics
aren't really allowed by the current spec.  But maybe they should be, I
don't know.

If we relax the specification in such a way as to allow that, then I
guess the most annoying consequence would be for people trying to do
permissions-preserving copies between filesystems mounted from different
server implementations.

>   exercise that just never seems to get settled.

The solution there is just to give up on the idea of agreeing on the One
True POSIX Mode->ACL Mapping:

	1. If you're a server, and you claim to support the ACL
	attribute, then you should support the whole thing and not some
	insane subset.  (Mea culpa.)
	2. If you're a client, then you should be ready to deal with
	whatever legal NFSv4 ACL you get.

That's why my current version of the POSIX<->NFSv4 mapping draft
requires a NFSv4->POSIX mapping that accepts pretty much everything.
That makes the draft what it should be: guidelines for ACL implementors,
not specification of a special sub-protocol that tunnels POSIX ACLs over
NFSv4.

--b.