Subject: [nfsv4] New I-D: draft-falkner-nfsv4-acls-00

From: Sam Falkner <[email-masked]>
Date: Mon, 17 Oct 2005 17:46:02 -0700

A new internet draft for ACLs is now available.  It makes some  
clarifications
regarding ACL semantics, and discusses supporting NFSv4 ACLs in a POSIX
environment, including adhering to POSIX standards while improving
interactions between the mode and ACL attributes.

We would like the working group chairs to consider this to be a work  
item
for this working group.

We would appreciate any feedback, comments, etc.  In all likelihood,  
there
will be a Solaris implementation of NFSv4 ACLs in the near future,  
and we
would like to reach a consensus on these issues.

In addition to discussion on this alias, we will both be attending  
the IETF
meeting in Vancouver, and hope to discuss this topic there.

Thanks!

- Sam

From: [email-masked]
Date: October 17, 2005 12:50:02 PM PDT
To: [email-masked]
Subject: I-D ACTION:draft-falkner-nfsv4-acls-00.txt
Reply-To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts  
directories.

     Title        : NFS Version 4 ACLs
     Author(s)    : S. Falkner, L. Week
     Filename    : draft-falkner-nfsv4-acls-00.txt
     Pages        : 35
     Date        : 2005-10-17

    NFS version 4 (specified in RFC 3530) Access Control Lists (ACLs)
    provide more fine grained control than previous file permission
    models, but before the full benefit of the model can be exploited,
    some changes and clarifications must be made.  This document will
    describe the details that implementors should consider in order to
    allow implementations to function and interoperate better.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-falkner-nfsv4-acls-00.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-falkner-nfsv4-acls-00.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-falkner-nfsv4-acls-00.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.
Content-Type: text/plain
Content-ID: <[email-masked]>

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: Andreas Gruenbacher <[email-masked]>
Date: Tue, 18 Oct 2005 21:14:28 +0200

Sam,

section 12 "ACE4_DELETE/ACE4_DELETE_CHILD Behavior" defines when files may be 
deleted:

>        if ACE4_EXECUTE is denied by the parent directory ACL:
>           deny delete
>        else if ACE4_EXECUTE is unspecified by the parent directory ACL:
>           deny delete
>        else if ACE4_DELETE is allowed by the target object ACL:
>           allow delete
>        else if ACE4_DELETE_CHILD is allowed by the parent directory ACL:
>           allow delete
>        else if ACE4_DELETE_CHILD is denied by the parent directory ACL:
>           deny delete
>        else if ACE4_ADD_FILE is allowed by the parent directory ACL:
>           allow delete
>        else
>           deny delete

I'm surprised to see ACE4_ADD_FILE show up here. Would you mind explaining? 
Thanks!

Regards,
Andreas.

-- 
Andreas Gruenbacher <[email-masked]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH

---

From: Sam Falkner <[email-masked]>
Date: Wed, 19 Oct 2005 11:11:06 -0700

> I'm surprised to see ACE4_ADD_FILE show up here. Would you mind  

Sure.  The idea is that ACE4_ADD_FILE is enabled (set on an ALLOW  
ACE) whenever
the directory is made writable (per section 5.3 of the draft).  Thus,  
if something like
"chmod 777 <directory>" were done, then deletes on that directory  
would be successful.

- Sam

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Fri, 21 Oct 2005 19:48:12 -0700

Notes from the NAS Conference in Santa Clara 10/18-10/20.
This doesn't capture all comments.

The IDENTIFIER_GROUP flag may be problematic for some
platforms, like NT. What does [email-masked] with IDENTIFER_GROUP==0
mean? NT doesn't allow both a user 'staff' and a group 'staff'.
The NT SIDs (Security Identifiers) are always unique. A lookup
of the SID will tell if its group/user/alias/etc.

NFSv4 ACLs are largely believed to be first match. This is
somewhat like POSIX ACLs being a directed match. NT ACLs,
I believe, can accumulate permissions. This might be only
when MAX_ALLOWED is used. The MAX_ALLOWED algorithm (if
I recall correctly) is:

	rights (principle, acl) {
		int	denied = 0, granted = 0;

		foreach ace in acl
			if match (ace->who, principle)
				if ace is ALLOW
					granted |= ace->rights &~ denied
				elseif ace is DENY
					denied |= ace->rights
				endif
			endif
		endfor
		return granted
	}

What happens if the name service is down? Effectively the UI
and API for ACLs would be disabled. If someone is trying to
change an ACL, this is usually a read-modify-write operation.
Substituting "nobody" for failed lookups ([email-masked]) gives
a bad read of ACLs through the API. If its modified and written
back, the ACL is trashed. Sam's take is the read should fail
to prevent this scenario.

How does DELETE/DELETE_CHILD interact? Sam and Lisa's draft has
pseudo-code. IBM's native ACLs require that DELETE be granted on
the object *AND* DELETE_CHILD be granted on the enclosing directory.
NetApp allows/denies the delete if DELETE on the object specifically
ALLOW/DENY. Otherwise, with the object effectively silent, DELETE_CHILD
on the parent directory is consulted. This is believed to be consistent
with NT behaviour.

There was a request in the audience for providing good tools
for managing ACLs on migrated datasets. How does an admin take
a large dataset (millions of files), move to an NFSv4 ACL capable
file system, and set the ACLs? I suppose something more than -R
is needed. It's a good question.

Sun (Sam and Lisa) are considering the API to native NFSv4 ACLs on
Solaris. Their approach is to add opcodes to acl(2) to get/set/count
the NFSv4 ACL. The existing opcodes for POSIX ACLs would continue to
work and the translation between POSIX and NFSv4 ACLs would be done
below the API.

Trond is experimenting with native NFSv4 ACLs on Linux. He'll use
the Linux getxattr(), and also translate between POSIX/NFSv4 ACLs.
Trond intends to save the "who" part of the ACL as a string just
like the protocol. This is quite interesting because it avoids the
name server problems. The "who" string will be saved 32-bit word
aligned. The comparisson can be done word at a time rather than
strcmp()ed. This is not unlike handling NT SIDs.

A brief conversation with Sergei of Hummingbird indicated that
there is not much difficulty translating between NT and NFSv4 ACLs.

I would like to see getxattr() on all platforms with consistent
attribute name and operand (value) data structures. It should
be possible to coordinate. Tar 'x' encoding rules should also
be defined.

Others who were at the NAS Conference, please post anything
I missed. Thanx.

Regards,
	-gww

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Sam Falkner
> Sent: Monday, October 17, 2005 5:46 PM
> To: [email-masked]
> Subject: [nfsv4] New I-D: draft-falkner-nfsv4-acls-00
> 
>

---

From: [email-masked]
Date: Thu, 27 Oct 2005 16:24:07 -0700

>A new internet draft for ACLs is now available.  It makes some clarifications

The draft nails down some semantics, relating v4 ACLs to both POSIX ACLs and good old mode bits.  Those clarifications may not be entirely consistent with Windows ACL semantics - perhaps the differences, if any, could be discovered and considered before finalizing this draft(?)

Conrad Minshall