Re: [NFS] [nfsv4] Re: NFSv4 ACL and POSIX interaction / mask, draft-ietf-nfsv4-acls-00 not ready

On Mon, Jul 10, 2006 at 05:26:32PM -0500, Sam Falkner wrote:
> 
> On Jul 10, 2006, at 1:57 PM, J. Bruce Fields wrote:
> >If we're committed to getting the mask ace right, though, I would
> >prefer to adopt one of Andreas's solutions; they'd allow us to
> >generate much simpler ACLs.  I actually prefer the first proposal
> >(letting the  server use the mode bits to mask out permissions).  But
> >if we're going to add explicit mask aces, then please, let's add only
> >one.  I understand the theoretical advantage to masking out all three
> >classes, but that's adding too much complexity for a few corner
> >cases, and I don't think it's going to be easy for users to
> >understand.
> 
> How would a scheme that uses one and only one mask ACE work?  Are you
> thinking of catching mode 077 via a
> 
> OWNER@:READ_DATA/WRITE_DATA/EXECUTE:DENY
> 
> but having no way to catch mode 707 (because GROUP@:READ_DATA/
> WRITE_DATA/EXECUTE:DENY might catch the owner)?

Andreas's proposal was actually to add something new to the protocol
(either a new attribute, or a new special entity (like "MASK@")) to
transfer the mask.  One of the advantages of doing that is that you'd no
longer have to use a bunch of DENY ACEs scattered through the ACL, all
carrying the same information.  E.g. you'd the client to include an ACE
like

	MASK@:READ_DATA:DENY

and modify the NFSv4 acl-permission-checking algorithm to mask out any
bitmasks anywhere other than OWNER@ or DENY@.

But Andreas was proposing that we actually add 3 different types of
masks, one for the OWNER@, one for EVERYONE@, and one for the others,
and I think that's overkill.  So that's what I'm arguing against.

> >We could add a new ACE type (in addition to ALLOW, DENY, AUDIT,
> >ALARM), and then a client could query the server's ability to
> >represent the  mask with the aclsupport attribute and decide whether
> >it wants to add  DENY's to represent the mask, or just give up on
> >chmod reversibility.
> 
> Please explain this further.  What would the fifth ACE type do?  What
> would it give you that DENY wouldn't?

It's just a way to pass the mask inside the ACL, but using a new ACE
type instead of a new special entity.

The advantage is that a client can actually probe to see if the server
supports it, so we wouldn't have to make it mandatory for a server to
support it.  But a separate attribute would also have that property.

--b.

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