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

From: [email-masked]
Date: Tue, 16 May 2006 15:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network File System Version 4 Working Group of the IETF.

	Title		: Mapping Between NFSv4 and Posix Draft ACLs
	Author(s)	: M. Eriksen, J. Fields
	Filename	: draft-ietf-nfsv4-acl-mapping-04.txt
	Pages		: 16
	Date		: 2006-5-16
	
A number of filesystems and applications support ACLs based on a
withdrawn POSIX draft [2].  Those ACLs differ significantly from NFS
version 4 (NFSv4) ACLs [1].  We describe how to translate between the
two types of ACLs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-acl-mapping-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-nfsv4-acl-mapping-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-nfsv4-acl-mapping-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 16 May 2006 17:57:56 -0400

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

---

From: Benny Halevy <[email-masked]>
Date: Mon, 29 May 2006 13:54:29 +0300

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.

This may contradict your POSIX->NFSv4 mapping algorithm as 
described in section 6.1 (second point numbered as "2" in 
this section?... maybe it'd be better to number these rules 
as 6.1.x.y so they could be easily referred to :). If so, I 
think that the mapping problem should be described as such.

Benny

[email-masked] wrote:
> ------------------------------------------------------------------------
>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 29 May 2006 11:47:58 -0400

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

---

From: Benny Halevy <[email-masked]>
Date: Tue, 30 May 2006 09:10:22 +0300

> ACL deny a bitmask when it would permit each bit in the mask

Hmm, I see your point taking all order permutations into 
account.