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

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 6 Apr 2006 15:32:10 -0400

>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)
	- 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)

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?

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.

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.

By the way, with this change, our mapping (in the mode bit case) would
be very close to Microsoft's services-for-unix mode bit mapping:

http://www.microsoft.com/technet/interopmigration/unix/sfu/sfu3perm.mspx#EFAA

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?

--b.

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