Re: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-04.txt

On Tue, May 16, 2006 at 03:50:01PM -0400, Internet-Drafts@ietf.org wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-acl-mapping-04.txt

The working group has complained that previous drafts describe the
POSIX->NFSv4 mapping very carefully, but say little about the reverse
direction.  Older drafts suggest rejecting any ACL that isn't in the
image of our POSIX->NFSv4 mapping.

This causes obvious problems for a server exporting POSIX ACLs: in
practice it is impossible for an unaided user to generate ACLs that
satisfy such a server.

But it also causes problems for a single server supporting heterogeneous
clients and applications (some using POSIX ACLs, some using NFSv4 ACLs
directly): imagine a user on a Windows client trying to set an ACL that
will be acceptable to someone else using POSIX ACLs.

So this draft describes an algorithm that accepts any NFSv4 ACL, while
erring on the side of mapping to a stricter ACL when an exact mapping
isn't possible.  The algorithm can also be adapted to err on the side of
permissiveness, for use by a client presenting an NFSv4 ACL as a POSIX
ACL.

I think people will like that.  A couple points need discussion, though:

	- I'd like to have the option of ignoring some bitmask bits
	  entirely.  On the server this breaks the "err on the side of
	  restricting permissions" rule--for example, we might accept an
	  ACL that denies READ_ATTRIBUTES with no intention of enforcing
	  it.  But it's painful to make every user learn rules about
	  which bitmask bits must be set to keep the POSIX world happy.

	- I'd like to allow a simplified POSIX->NFSv4 mapping; currently
	  we represent 644 with something like (assuming default deny,
	  and ignoring mode bit mapping):

		ALLOW OWNER@	rw-
		DENY OWNER@	--x
		ALLOW GROUP@	r--
		DENY GROUP@	-wx
		ALLOW EVERYONE@	r--

	  It would more user-friendly, more windows-friendly, and just
	  as correct, to use:

		ALLOW OWNER@	rw-
		ALLOW GROUP@	r--
		ALLOW EVERYONE@	r--

	  The problem is that while anyone using the new NFSv4->POSIX
	  mapping will be able to accept either of these, older
	  implementations may not cope so well.

--b.

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