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

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 29 May 2006 15:03:30 -0400

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:[email-masked]]
Sent: Monday, May 29, 2006 11:48 AM
To: Benny Halevy
Cc: [email-masked]; [email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 29 May 2006 15:26:09 -0400

> and the other open for write.

Exactly.  That's why I'm describing it as an "eccentricity" rather than
a feature we should worry about emulating.  I wanted to document it, but
I really don't think it's important....

(Things I *do* think are important

	- How can we get away from requiring servers exporting backend
	  posix acls (and clients with posix acl interfaces) from being
	  quite so picky about mask bits?

	- How can we transition to a mapping that doesn't insist on so
	  many interleaved denies without breeaking backwards
	  compatibility?
)

--b.