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

From: [email-masked]
Date: Fri, 28 Jul 2006 11:50:58 -0400 (EDT)

I'm a simple minded guy and I got lost on this so long ago it isn't worth
mentioning. So, I'm going to throw out what I think should be done. I don't
expect anyone to buy into it, but you asked for comments before the meeting,
so here goes...

I don't think the RFC should say anything about how the client chooses to
handle the Mode and ACL attributes. If a posix-like client wants to set
both an ACL and Mode bits for chmod(2) syscall, that is up to the client
implementors.

(All comments w.r.t. RFC3530)
I think what goes on the wire is pretty clear, so I think what is left is
to clarify what the server does w.r.t. Mode and ACL:
Since doing a Setattr on any other attribute only "Sets" that attribute,
I believe that the same should be true of Mode and ACL. (In other words,
toss Sec. 5.11.6, because I think the seemingly endless discussion is
evidence that you can't do it right and any attempt just causes endless
confusion.)

That leaves:
- The "access is undefined" case for bits left over (3rd para of 5.11).
   - I can see three possibilities. I don't care which of the 3 is chosen,
     but I do think interoperability would be enhanced by choosing one of
     them.
     - Deny
     - Allow
     - Use the Posix mask bits (My current server code does this, but I am
	not strongly in favour of it.)
- What about the case where no ACL has been set on the file. I would have
  preferred that the server just not return an ACL, but since Sec. 14.2.7
  doesn't allow that, so...
  Define the ACL with no entries as "No ACL for this file". (empty ACL)
  (If Windows has a different notion of what an empty ACL is, then the
   Windows clients can deal with that case by generating a non-empty ACL that
   represents what Windows considers an empty ACL to mean.)
- How a server uses Mode and ACL for permission checking?
  - If there is an ACL for the file
	- use the ACL and ignore the Mode bits
    else /* empty ACL, as above */
	- use the Mode bits

Just my opinion on a simple way to deal with the problem, rick

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

---

From: Jim Rees <[email-masked]>
Date: Fri, 28 Jul 2006 12:03:32 -0400

The Apollo file system tried to keep mode bits and acl in sync, and it was
horribly confusing.  Afs ignores the mode bits and just uses the acl, and it
works much better, in my opinion.  So I agree with Rick on this one.

---

From: [email-masked]
Date: Fri, 28 Jul 2006 12:57:50 -0400

>> -----Original Message-----
>> From: Jim Rees [mailto:[email-masked]] 
>> Sent: Friday, July 28, 2006 12:04
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: Re: [nfsv4] re: ACL and Posix Mode bit interaction 
>> 
I believe you mean "no ACL" use the mode-bits.

---

From: Jim Rees <[email-masked]>
Date: Fri, 28 Jul 2006 13:21:45 -0400

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.

But I'll defer to Rick on this.

---

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

> 	not strongly in favour of it.)

Note that the current 4.1 draft is requiring Deny, so if that's a
problem then object now....

>     else /* empty ACL, as above */

.... and I don't think the current draft makes this special exception
for this case, so under 4.1 a zero-length ACL would deny everything to
everyone.

--b.

---

From: Lisa Week <[email-masked]>
Date: Fri, 28 Jul 2006 13:20:44 -0600

>for this case, so under 4.1 a zero-length ACL would deny everything to

Actually, there is a distinction between no ACL and a zero length ACL.  
Since the mode and ACL are kept in sync (per RFC3530 and 4.1) a zero 
length ACL would by definition deny everything to everyone and also 
cause the mode to be 000.

Having no ACL ever being set on a file would leave the mode unchanged.  
If an ACL has never been set on a file and the server is asked for an 
ACL, we will return an ACL that is a representation of the mode.

- Lisa

---

From: Lisa Week <[email-masked]>
Date: Fri, 28 Jul 2006 13:57:41 -0600

>works much better, in my opinion.  So I agree with Rick on this one.
Having the situation where the mode bits and the ACL are out of sync 
would be more confusing.

Consider a client that only supports modes.  What kind of semantics 
would out-of-sync modes and ACLs give them if they are running against a 
server that supports both modes and ACLs?  In that case, an application 
on the client which sets the mode will have no effect on the permissions 
of the file because if there is an ACL then mode bits will get ignored.  
Seems bad.

Even outside of whether or not the client supports ACLs, if an 
application is relying on the setting of a mode to take effect and to 
give reasonable semantics (that it sets the appropriate permission bits 
for owner, owner_group and other), the ACL *and* the mode must be kept 
in sync.

---

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

On Fri, Jul 28, 2006 at 01:57:41PM -0600, Lisa Week wrote:
> Consider a client that only supports modes.

It could be even worse--the server doesn't have to support modes at all.

And if clients can deal with the complete absence of modes, I suppose
they can also deal with modes that aren't synchronized with ACLs.

> What kind of semantics would out-of-sync modes and ACLs give them if
> they are running against a server that supports both modes and ACLs?
> In that case, an application on the client which sets the mode will
> have no effect on the permissions of the file because if there is an
> ACL then mode bits will get ignored.  Seems bad.

Well, people tell us there have been succesful systems that have been
bad in this particular way, and people learned to live with it....

--b.

---

From: Sam Falkner <[email-masked]>
Date: Fri, 28 Jul 2006 16:50:22 -0600

> they can also deal with modes that aren't synchronized with ACLs.

One of the goals that will be in the next rev of the ACL section of  
minorversion1 will be that a client that only uses modes will see  
reasonable semantics from a server that supports modes, and a client  
that uses only ACLs will see reasonable semantics against a server  
that supports ACLs.

This is supported today, with RFC 3530.  NetApp, EMC, AIX, Solaris...  
every server I know of that supports NFSv4 ACLs meets the above goal  
today.  I see no compelling reason to break this.

> bad in this particular way, and people learned to live with it....

Huh?

- Sam

---

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

> >bad in this particular way, and people learned to live with it....

As Jim points out, AFS didn't try to get the mode bit and ACL
interaction perfect[1].  And that didn't seem to hurt it much.

--b.

[1] Although AFS doesn't totally ignore the mode either; see

	http://www.openafs.org/pages/doc/UserGuide/auusg007.htm#HDRWQ59

for details.