Re: [nfsv4] simplifying POSIX->NFSv4 ACL mapping

[Andreas Gruenbacher <[e-mail]>]

On Thursday, 06 April 2006 21:32, J. Bruce Fields wrote:
 >From thinking about Windows interoperability and our POSIX->NFSv4
> mapping, I've noticed some changes to the mapping that might simplify
> things quite a bit.
>
> In particular, I'd like to fit most POSIX-mapped ACLs into one of two
> subsets:
>
> 	- Allow-only ACLs: ACLs without any DENY ACEs at all (except for
> 	  possibly a DENY at the end to enforce a default-DENY policy)

That's what the following statement in draft-ietf-nfsv4-acl-mapping-04.txt now 
describes. I suppose you have put this statement there with Marius exactly 
for this purpose:

   If the bitmasks in the resulting ACEs are non-increasing (so no ACE
   allows a bit not allowed by a previous ACE), then we can skip the
   next step.

> 	- Deny-first ACLs: ACLs that, if they have any DENY ACEs at all,
> 	  have them all that the start (except for possibly a DENY at
> 	  the end to enforce a default-DENY policy)

Not an option for mapping POSIX ACLs: with all deny entries first, owners who 
are also in the owning group would be denied owning group permissions before 
being granted owner permissions, and the nfsv4 acl permission check algorithm 
would terminate there (among other problems).

> Though the Windows NFSv4/ACL model isn't necessarily complex to
> describe, it can be used in complex ways--POSIX-mapped ACLs are a great
> example of this.  Unfortunately, this leads to usability problems--for
> example, how do you write tools that allow simple operations like "give
> user X write permissions to file Y" and that can operate on arbitrary
> NFSv4 ACLs?

Indeed, I would have preferred a MASK@ entry extension in nfsv4 acls instead 
of pairing all ALLOW entries with DENY entries for the mask. Instead, we now 
end up with monsterous NFSv4 ACLs in some cases. In addition, a simple chmod 
can cause additional entries to get introduced now, which can lead to ENOMEM 
or ENOSPC, which may make things quite "interesting".

> It would help if by default we produced allow-only (or at least
> deny-first) ACLs.  That's also (more or less) what common Windows tools
> seem to expect.

Common Windows tools produce deny-first ACLs, indeed. That won't work for us, 
unless there are no deny ACEs at all.

> Currently the POSIX->NFSv4 mode bit mapping *never* produces allow-only
> ACLs, even though in most cases the DENY ACE's it includes are
> completely unnecessary.
>>
> For example, we're inserting DENY aces after every ALLOW ace in order to
> enforce the POSIX first-match semantics.  But those DENY's are
> superfluous in cases like the mode 644, where permissions are
> non-increasing.  And that's almost certainly the common case--of the
> 700,000 files on my laptop, for example, there are only six exceptions.
> Of those, three (with modes 645 and 745), were just mistakes on my part,
> the other three were actually produced by ACL tests.
>
> So leaving out the superfluous DENYs from the POSIX ACL/mode bit
> mappings would make a lot of typical ACLs allow-only.

Makes sense.

> There are also common cases where we could remove the DENY aces that we
> get from the posix mask ace--for example, whenever the mask ace is the
> same as the group ace and is no more restrictive than any of the named
> user/group aces.
>
> We could try to do this in a backwards-compatible way by just making
> clients that care throw out superfluous DENYs before presenting ACLs to
> the user (as long as the ACEs really are no-ops, there's no harm to
> this).  But as long as we're doing that, I'd really rather we just
> eliminated those DENY's everywhere.
>
> Comments?

The resulting NFSv4 ACLs are more useful, so I like those changes, thanks.

Thanks,
Andreas

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