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

From: [email-masked]
Date: Wed, 11 Feb 2004 15:51:39 -0500

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
	Filename	: draft-ietf-nfsv4-acl-mapping-01.txt
	Pages		: 10
	Date		: 2004-2-11
	
The NFS (Network File System) version 4[rfc3530] (NFSv4) specifies a
flavor of Access Control Lists (ACLs) that apply to file system
objects.  ACLs specify an access level for a number of entities. The
NFSv4 ACLs model resembles that of Windows NT.  A POSIX
draft[posixacl] proposes another, more restrictive ACL model.  Many
systems implement this proposed standard.  Differing in syntax,
semantics and extensiveness, it is only feasible to create a correct
representation for POSIX ACLs with NFSv4 ACLs.  This does not hold
for an attempt to represent arbitrary NFSv4 ACLs with POSIX ACLs.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 11 Feb 2004 17:55:06 -0500

> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-acl-mapping-01.txt

Note that anyone that cares about how to keep mode bits and acl's in
sync also needs to pay some attention to this.

I think what we're now proposing is consistent with what's been
discussed on this list, but speak up if anything looks wrong:

posix read bit = ACE4_READ_DATA | ACE4_READ_NAMED_ATTRS
posix write bit = ACE4_WRITE_DATA | ACE4_WRITE_NAMED_ATTRS
			| ACE4_APPEND_DATA | ACE4_DELETE_CHILD
		(though ACE4_DELETE_CHILD actually only has meaning on
		 directories)
posix execute bit = ACE4_EXECUTE_BIT | ACE4_READ_DATA

Also, everyone gets ACE4_READ_ATTRIBUTES | ACE4_READ_ACL, and the
owner (and only the owner) gets ACE4_WRITE_ATTRIBUTES | ACE4_WRITE_ACL.
Also (I just realized this got left out of the above draft), everyone
should get DELETE (at least on files).

We're making some assumptions here:
	1. ACE4_WRITE_DATA (and ACE4_APPEND_DATA?) are sufficient to
	   allow someone to modify the length of a file;
	   ACE4_WRITE_ATTRIBUTES is not required.
	2. ACE4_WRITE_ATTRIBUTES does not give the right to modify mode
	   bits, ACLs, or named attributes
	3. ACE4_DELETE_CHILD on the directory is always required for
	   unlink to succeed; ACE4_DELETE doesn't allow this to be
	   bypassed.  (Mitch Halevy's interpretation that ACE4_DELETE
	   would only be checked when removing the last link made sense
	   to me.)

Arguments welcomed.--b.

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

---

From: "Benny Halevy" <[email-masked]>
Date: Wed, 11 Feb 2004 20:14:10 -0500

Folks, first, the draft looks much more sensible than its previous
version.

1) IMO NFSv4 "OWNER", "GROUP", and "EVERYONE" better be referred as
"OWNER@", "GROUP@", and "EVERYONE@" respectively. See rfc3530
section 5.11.6.  Mode and ACL Attribute

2) A couple of technical comments:
- NFSv4 is now rfc3530 not rfc3010.
- there are a lot of control characters in the text (backspaces?)

3) The draft could use an example.

4) It'd be great if as the next step we define how a POSIX compliant server
should support NFSv4 ACLs.  What NFSv4 ACE types and flags can be supported
and how they should be translated into the posix model.

Regards,

Benny (who's Mitch?) Halevy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of J.
> Bruce Fields
> Sent: Wednesday, February 11, 2004 17:55
> To: [email-masked]
> Subject: Re: [nfsv4] I-D ACTION:draft-ietf-nfsv4-acl-mapping-01.txt
> 
>

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 11 Feb 2004 20:38:38 -0500

Thanks for the comments.

> and how they should be translated into the posix model.

By a "POSIX-compliant" server, do you mean a server that's using posix
acl's on the exported filesystem to store ACL's?  We're doing that right
now in Linux by rejecting any acl handed to us by a client that isn't
*exactly* the ACL that would be produced by the mapping described in the
draft.  This has the advantage that ACL's that are accepted can be
returned unmodified.  Some more flexibility might be possible.

> Benny (who's Mitch?) Halevy

Crap, I apologize, my mind's playing tricks on me.--Bruce Fields

---

From: "Benny Halevy" <[email-masked]>
Date: Wed, 11 Feb 2004 23:10:39 -0500

I've been thinking more about the READ and WRITE NAMED_ATTRS
ACE access masks and I think I have more questions than
answers at this point.

In draft-ietf-nfsv4-acl-mapping-01.txt you tie these access masks
with READ and WRITE DATA respectively. Is this the right thing to do?

How do clients use named attributes?
I guess these would be typically used to store additional information
about filesystem objects like "Description", "Title", "Author",
"Version", "Checksum", etc.  For example, I look at Microsoft's
custom file properties.  These are organized hierarchically in named
groups, each having a list of named properties having a type and
a value.  These fit pretty well into the named attributes model
but the question here is whether access control for these attributes
is tied with access to the file data?  Or should it be tied to the
access control for the file's attributes? (in posix that means
readable to everybody and writable to owner and privileged users)

Say you want to present some of the named attributes such
as "Description" or "Artist" or "Icon" when listing a directory.
You would want to be able to read their contents even when you are
not allowed to read the file's data.

Benny

---

From: Marius Aamodt Eriksen <[email-masked]>
Date: Wed, 11 Feb 2004 23:39:05 -0500

> with READ and WRITE DATA respectively. Is this the right thing to do?

while there does not seem to be any defined behavior in posix for this; 
the extended attributes implementation in linux implements this scheme 
(and is why we adapted it).

> not allowed to read the file's data.

the problem is that there is no way to express this with posix acls.  
however the scheme we have adapted is consistent with what is being 
used together with posix acls in real systems today.  but i do agree -- 
some users may wish for finer granularity, but we will not be able to 
express that in terms of posix ACLs.

marius.

--
marius a eriksen <[email-masked]> | 
http://www.citi.umich.edu/u/marius/