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

From: "Yoder, Alan" <[email-masked]>
Date: Fri, 28 Jul 2006 15:44:32 -0700

see below...

> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]] 
> Sent: Friday, July 28, 2006 3:07 PM
> To: Lisa Week
> Cc: [email-masked]; Jim Rees; [email-masked]
> Subject: Re: [nfsv4] re: ACL and Posix Mode bit interaction
> 
> On Fri, Jul 28, 2006 at 01:57:41PM -0600, Lisa Week wrote:
> > 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.
> 
> 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....
> 

Not sure if you're referring to me here?  Our system does
synchronize modes and ACLs.  

 * It's easy to synthesize an ACL given a mode, if you
   need to.  Next.

 * For v3 clients statting files with ACLs, we gin up
   a mode that is at least as restrictive as the ACL.
   So a client that checks perms before accessing a file
   might think it couldn't open the file when in fact it
   can.
   
 * For v2 clients statting files with ACLs, I believe we
   now gin up a mode that is at least as permissive as
   the ACL.  This is so that v2 clients--which do check
   before accessing a file--won't mistakenly assume they 
   can't access a file and return EACCESS when in fact if
   they just went ahead and tried, they would succeed.

In all cases, if a file has an ACL, that's what's used to
actually check the permissions.  The mode is just for stat
and display purposes.  If it doesn't have an ACL, then there's
nothing to synchronize.

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
=============================================================== 

> --b.
> 
> _______________________________________________
> 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: [email-masked]
Date: Sat, 29 Jul 2006 14:45:39 -0400 (EDT)

First off, if this is explained/resolved in the current draft, just tell
me to "piss off and read it":-) I've looked at the NFSv4<->POSIX ACL draft,
but not the 4.1 draft.
But, in case it isn't covered in the draft...

>  * It's easy to synthesize an ACL given a mode, if you

Everyone seems to be saying this, but it doesn't seem so easy to me.
For example, a file "test" owned by rick has hard links in two directories:
drwxr-xr-x  2 andrew  wheel  512 Jul 29 13:41 bar
drwx------  2 rick    wheel  512 Jul 29 13:41 foo

Now, I can see that rick can delete foo/test and andrew can delete bar/test.
How does this get expressed in the ACL synthesized from the Mode bits for
"test"? (ie. What about ACEs for DELETE?)

I suppose an ACL could have been synthesized when the file was first created,
with DELETE ACE(s) built from the directory's Mode bits. But then, how does the
server "massage" this ACL when the second hard link is created?

Under RFC3530, if you didn't generate any ACEs with DELETE in them, it
would be "undefined", which could be construed to mean "check the link's
directory ACL". But, under 4.1 it sounds like the answer is Deny instead
of undefined, unless ACEs for DELETE are in the ACL?

If the ACL synthesized from Mode bits doesn't handle this case and is only
approximate, the semantics of "deletion" changes when the ACL is synthesized.

> and display purposes.  If it doesn't have an ACL, then there's

And what do you return when a v4 client does a Getattr/ACL for files that don't
have ACLs? Synthesize it at that point and create subtly different permission
semantics for the file as a result?

Still Confused by ACLs, rick

---

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 29 Jul 2006 16:55:46 -0400

> First off, if this is explained/resolved in the current draft, 
> just tell me to "piss off and read it":-) I've looked at the 
> NFSv4<->POSIX ACL draft, but not the 4.1 draft. 

Actually I don't think it is.  Maybe I missed it but there doesn't 
seem to be a section on synthesizing an ACL from a mode when ACL hasn't
been set.

> "test"? (ie. What about ACEs for DELETE?)

The only conclusion I can draw is that the synthsized ACL does not
specify
ACE's with delete.  If you did, then you would be able to delete the
file
independent of the path used and you don't want to do that.

I think according to the algorithm in section 5.2.1, this means that the
deletion decision will be made according to permissions in the directory
as you want.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Saturday, July 29, 2006 2:46 PM
To: [email-masked]
Cc: [email-masked]; Yoder, Alan; [email-masked]; [email-masked]
Subject: [nfsv4] re: ACL and Posix Mode bit interaction

First off, if this is explained/resolved in the current draft, just tell
me to "piss off and read it":-) I've looked at the NFSv4<->POSIX ACL
draft, but not the 4.1 draft.
But, in case it isn't covered in the draft...

Everyone seems to be saying this, but it doesn't seem so easy to me.
For example, a file "test" owned by rick has hard links in two
directories:
drwxr-xr-x  2 andrew  wheel  512 Jul 29 13:41 bar
drwx------  2 rick    wheel  512 Jul 29 13:41 foo

Now, I can see that rick can delete foo/test and andrew can delete
bar/test.
How does this get expressed in the ACL synthesized from the Mode bits
for "test"? (ie. What about ACEs for DELETE?)

I suppose an ACL could have been synthesized when the file was first
created, with DELETE ACE(s) built from the directory's Mode bits. But
then, how does the server "massage" this ACL when the second hard link
is created?

If the ACL synthesized from Mode bits doesn't handle this case and is
only approximate, the semantics of "deletion" changes when the ACL is
synthesized.

> In all cases, if a file has an ACL, that's what's used to actually 
> check the permissions.  The mode is just for stat and display 
> purposes.  If it doesn't have an ACL, then there's nothing to 
> synchronize.

And what do you return when a v4 client does a Getattr/ACL for files
that don't have ACLs? Synthesize it at that point and create subtly
different permission semantics for the file as a result?