RE: [nfsv4] Re: Minor Eccentrity of POSIX ACLs

It doesn't seem that this eccentricity, or rather RFC3530's
failure to emulate it, results in any negative security 
consequences.  If you allow someone to open a file for 
reading and open that same file for writing, not allowing
him to open for both, does not interfere with his access to
the file, except in adding a degree of inconvenience.  
Everything you can do with a file open for read and for
write can be done with two open files, one open for read
and the other open for write.

-----Original Message-----
From: J. Bruce Fields [mailto:bfields@fieldses.org]
Sent: Monday, May 29, 2006 11:48 AM
To: Benny Halevy
Cc: marius@citi.umich.edu; nfsv4@ietf.org
Subject: [nfsv4] Re: Minor Eccentrity of POSIX ACLs

On Mon, May 29, 2006 at 01:54:29PM +0300, Benny Halevy wrote:
> In draft-ietf-nfsv4-acl-mapping-04.txt, section 5 you say 
> that the following POSIX semantics cannot be expressed with 
> NFSv4 ACLs:
> 
> |   if a requester that is a member of more than one
> |   group listed in the ACL requests multiple bits 
> simultaneously, the
> |   POSIX algorithm requires all of the bits to be granted 
> simultaneously
> |   by one of the group ACEs.  Thus a POSIX ACL such as
> |
> |     ACL_USER_OBJ: ---
> |     ACL_GROUP_OBJ: ---
> |     g1: r--
> |     g2: -w-
> |     ACL_MASK: rw-
> |     ACL_OTHER: ---
> |
> |   will prevent a user that is a member of groups g1 and g2 
> from opening
> |   a file for both read and write, even though read and 
> write would be
> |   individually permitted.
> |
> |   The NFSv4 ACL permission-checking algorithm has the 
> property that it
> |   permits a group of bits whenever it would permit each bit
> |   individually, so it is impossible to mimic this 
> behaviour with an
> |   NFSv4 ACL.
> 
> Please correct me if I'm wrong but I think that this posix 
> eccentricity can be expressed with NFSv4 ACLs by having 
> explicit GROUP@ or group deny ACEs after each respective 
> GROUP@ or group allow ACE.

No.  Try writing down your example explicitly and tracing through the
algorithm described in rfc3530.  There's just no way to make an NFSv4
ACL deny a bitmask when it would permit each bit in the mask
individually.

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4