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

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 28 Jul 2006 16:32:34 -0400

This text can be read in many ways, which is a good thing for 
poetry but not for a spec :-).  I've created issue 95 for
this.

My interpretation has always been that "cannot approximate a
useful value" is referring to situations such as being unable 
to read the acl bits (io errors and such), and not to the kind 
of routine situation of someone not setting that particular 
attribute.  After all, we don't give people an error when they 
read the mode and nobody set a mode when creating the file.

I think the choice here is whether the first sentence is to be
ignored, and you are free to do anything you want, or whether you
assume there is some intention behind it, the imprecise specification
notwithstanding.

> If you believe that the server must return an ACL, then your choices
seem
> to be:
> - return an empty ACL for "no ACL"

Which doesn't distinguish this case from the real case of setting an
empty ACL which would let nobody do anything with the file, except where
the server makes specific exceptiosn for root or owner etc.  Yuck.

> OR
> - generate a fake one, which then leads to the POSIX Mode->ACL mapping
>   exercise that just never seems to get settled.

I don't believe that we've ever had a problem mapping a mode to an ACL,
when an ACL has not been set.  All of the problems center around mapping

ACL to mode (whether setting ACL should change mode) and mapping a
change 
in mode to a change in an existing ACL (whether and how a change in mode

should change the ACL).

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Friday, July 28, 2006 2:11 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [nfsv4] re: ACL and Posix Mode bit interaction 

>   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

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

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 28 Jul 2006 17:01:58 -0500

> read the mode and nobody set a mode when creating the file.

The other intent was the reason for recommended attributes in the
first place.  The server is just unable to provide a value unless
it lies or guesses badly.  That has obviously be conflated in the
text and also asks the question of whether the server should have
claimed support for the attribute to begin with.  The unfortunate
transition between intent/english-language specification/code.

Spencer