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

From: "Yoder, Alan" <[email-masked]>
Date: Mon, 31 Jul 2006 11:11:51 -0700

inline 

> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]] 
> Sent: Monday, July 31, 2006 8:57 AM
> To: Yoder, Alan
> Cc: Noveck, Dave; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [nfsv4] re: ACL and Posix Mode bit interaction
> 
> On Sat, Jul 29, 2006 at 02:36:51PM -0700, Yoder, Alan wrote:
> >    The directories and hard links each have separate ACLs.
> 
> I don't understand.  You're not suggesting returning different ACLs
> depending on which way the file was looked up, are you?  I don't think
> that's a good idea.

   After double-checking, I think you're right.  Chmod'ing
a hard linked file changes the permissions on all the links.

   But the answer really concerned the directories, which are
still free to have separate permissions. 

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
=============================================================== 
> 
> > In a directory, "w" == CREATE_CHILD + DELETE_CHILD + ....
> > There's no correspondent in the mode bits for DELETE on a
> > file that I can think of.  
> > 
> >    Possibly we need a table specifying this mapping.
> 
> See  the "ACE4_DELETE vs. ACE4_DELETE_CHILD" section of the 4.1 draft
> for a discussion of the semantics of those bits.
> 
> If you're following the recommendations of that section, then you
> probably want DELETE always to be cleared on mode-bit-derived ACLs.
> 
> I believe the mapping linux and solaris are currently using 
> produces an
> ACL like:
> 
> 	OWNER@:ALLOW:owner bits
> 	OWNER@:DENY:~owner bits
> 	GROUP@:ALLOW:group bits
> 	GROUP@:DENY:~group bits
> 	EVERYONE@:ALLOW:other bits
> 	EVERYONE@:DENY:~other bits
> 
> where those bitmasks are determined by mapping the
> 
> 	read mode bit to READ_DATA
> 	write mode bit to WRITE_DATA|APPEND_DATA (on files)
> 			  WRITE_DATA|APPEND_DATA|DELETE_CHILD 
> (on directories)
> 	execute bit to EXECUTE
> 
> and also turning on READ_ACL, READ_ATTRIBUTES, and SYNCHRONIZE
> unconditionally, and adding WRITE_ACL and WRITE_ATTRIBUTES to 
> the owner
> bits.
> 
> Note that in the case where the owner, group, and other bits 
> are ordered
> from least-to-most restrictive, the DENY's are unnecessary.  Some day
> soon I intend to modify the Linux implementation to stop 
> inserting those
> unnecessary DENY's.
> 
> The documentation for Microsoft's "Services for UNIX" also gives an
> example of Windows ACL->mode bit mapping which is pretty 
> similar to the
> above (with DENY's inserted only as necessary).
> 
> http://www.microsoft.com/technet/interopmigration/unix/sfu/sfu
> 3perm.mspx#EFAA
> 
> --b.
> 

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 31 Jul 2006 14:36:05 -0400

> still free to have separate permissions. 

Yep.--b.