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

From: [email-masked]
Date: Wed, 23 Aug 2006 15:50:02 -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-05.txt
	Pages		: 20
	Date		: 2006-8-23
	
A number of filesystems and applications support ACLs based on a
   withdrawn POSIX draft [2].  Those ACLs differ significantly from NFS
   version 4 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-05.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-05.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-05.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: Wed, 30 Aug 2006 12:30:41 -0400

> 	Filename	: draft-ietf-nfsv4-acl-mapping-05.txt

So the problem here has been that a server implementing this mapping is
so picky that a user *must* use a posix acl utility to set acls.  That
means we have to provide both posix and nfsv4 acl utilities and train
them to use one or the other depending on which server they're talking
to (or which filesystem them server is exporting).

In practice, since the posix acl utility will work (more or less) on
both, that means they'll probably just use it.  But this saddles all the
servers with weird requirements of the similarly picky client-side
mapping.

We're all working on implementing NFSv4 ACLs natively on our server
filesystems, which will solve the problem for new filesystems.

This draft solves the problem as completely as possible without
requiring a filesystem upgrade, by making a server exporting a posix-acl
filesystem support a much wider range of NFSv4 ACLs.

Changes to this draft:

	- sketches argument that the mapping actually takes any NFSv4
	  ACL to the unique POSIX ACL that is "closest" to the given NFSv4
	  ACL without being more permissive[1];
	- includes new description of the NFSv4->posix ACL mapping that
	  should be easier to implement from;
	- includes discussion of compatibility with old mapping, with a
	  brief description of the old mapping.

I've implemented the new NFSv4->posix mapping in the Linux server, and
could post some cleaned-up sample code at some point.

So the point of all this is that there's no longer any excuse for a
server (even one with backend posix acls) not to accept close to the
full range of NFSv4 ACLs.

--b.

[1]  Gory details: by the "closest" ACL we mean the most permissive ACL
that isn't more permissive than the given ACL.  The POSIX ACL is unique
only up to some choices of mask and inheritance flags.  Some ACLs (such
as acls with explicit denies of read_attributes, or that use unsupported
inheritance flags) may still have to be rejected.