Subject: [nfsv4] Windows/NFSv4 ACL interoperability

From: "J. Bruce Fields" <[email-masked]>
Date: Sun, 12 Mar 2006 17:40:35 -0500

Several of us had a conversation about ACL interoperability at
Connectathon the other week, and I just wanted to post some kind of
summary.

Apologies for the cross-posting; this seemed the most efficient way to
reach the people likely to be interested.  Let me know if there's
interest, and I could set up a dedicated mailman list for ACL
discussions.

So I've started gathering what I know here; corrections welcomed:

http://wiki.linux-nfs.org/index.php/ACLs#The_ACL_Interoperability_Problem

An executive summary: the basic problem, shared to some degree by NFSv4
and Samba, is that we'd like to support applications that use both POSIX
and Windows ACLs, and we'd even like to be able to do it from servers
(like Linux) that only support the less-fine-grained POSIX ACLs.  (At
some point that may mean just pushing Windows/NFSv4 ACLs into those
operating systems--I believe OSX, AIX, and Solaris are among those that
are already doing this.)

((There's also a problem that the NFSv4 spec is a little vague about the
semantics of NFSv4 ACLs, and that the ACLs it describes differ slightly
from Windows ACLs--see
http://www.ietf.org/internet-drafts/draft-falkner-nfsv4-acls-00.txt for
a proposal to address this).

Some points made by people at the meeting:
	- The problem as stated above is impossible to solve completely.
	  For example, ACLs that represent typical Windows expectations about
	  ALLOW/DENY ace ordering appear to be incompatible with ACLs that
	  represent mode bit semantics accurately.  So we have to be realistic
	  about what we can and can't do, and figure out ways to fail
	  gracefully.
	- Despite the ubiquity and flexibility of Windows ACLs, it may
	  be hard to abandon POSIX ACLs, because they can be somewhat
	  simpler to understand and manipulate, and because some common tools
	  may be starting to support them (e.g., see news about Nautilus ACL
	  support:
	  http://blogs.sun.com/roller/page/alvaro?entry=nautilus_acl_support)

Some resources mentioned at the meeting:
	- rfc3530 section 5.11 describes NFSv4 ACL's:
	  http://www.ietf.org/rfc/rfc3530.txt
	- Windows ACL documentation:
	  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_security_and_access_rights.asp
	- withdrawn draft "POSIX" ACL spec:
	  http://wt.xpilot.org/publications/posix.1e/download.html
	- Microsoft documentation on mode bit<->ACL mapping:
	  http://www.microsoft.com/technet/interopmigration/unix/sfu/sfu3perm.mspx
	- Microsoft documentation on preferred ACE ordering:
	  http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/security/order_of_aces_in_a_dacl.asp
	- Presentation by Jeremy Allison on POSIX<->Windows ACL mapping:
	  http://www.citi.umich.edu/projects/nfsv4/jallison-acl-mapping/jallison-acl-mapping.html
	- POSIX<->NFSv4 mapping, used by Linux and Solaris:
	  http://www.citi.umich.edu/projects/nfsv4/rfc/draft-ietf-nfsv4-acl-mapping-03.txt
	- Documentation of OSX ACLs:
	  http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Concepts/chapter_3_section_9.html
	- Proposed revisions to NFSv4 ACLs, discussion of chmod, mode bit
	  mapping, etc.:
	  http://www.ietf.org/internet-drafts/draft-falkner-nfsv4-acls-00.txt

But of course I probably missed some stuff; if you notice anything,
please let me know.

--b.

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

---

From: [email-masked]
Date: Tue, 14 Mar 2006 01:58:33 -0800

>operating systems--I believe OSX, AIX, and Solaris are among those that

Yes the OSX ACL model is nearly Windows.  IMO the most interesting 
difference between them is when none of the ACEs ALLOW or DENY an 
access.  In that case Windows denies the attempt, but OSX at that 
point will fall back to POSIX mode bits.

---

From: [email-masked]
Date: Tue, 14 Mar 2006 22:31:43 +1100

Christoph,

 > I think you are missing one distinctive difference in the semantics of
 > nfsv4 and windows acl: inheritance! afaik nfsv4 uses static inheritance
 > (acls are inherited only at file creationt time) and windows uses a
 > semi-dynamic model (acls are inherited at the time they are set).
 > Applications that rely on one behaviour may do strange things!

I am a little skeptical about this. I know that Microsoft docs talk
about this type of dynamic inheritance, but when I went to implement
it in Samba4 I failed to reproduce it in windows->windows testing
(using win2003). What I saw instead was that the windows client would
walk the file tree under the directory and update the ACLs manually
guided by the various inheritance flags.

Try as I might to make windows do true dynamic inheritance, where an
update to a directory acl is immediately visible elements within the
directory without a tree walk I didn't see it.

Some people have said they just don't believe me, but I would
appreciate it if someone who has seen real dynamic inheritance in
action could send me a sniff demonstrating it.

Also note that (from the users point of view) Samba4 does implement
dynamic inheritance, its just that what happens is the client
transparently walks the tree and updates it for us, so I have a
working implementation to backup the above :-)

Cheers, Tridge

---

From: [email-masked]
Date: Tue, 14 Mar 2006 23:13:20 +1100

Christoph,

 > Yes, we are taliking about the same thing. Thats why i said semi-dynamic
 > and applied at the time the ace is set, and not when the actual access
 > check happens! But as this behaviour is not exposed to the windows user (he
 > always has the feeling he's working on a fully dynamic inheritng fs),
 > and should be obeyed by applications (don't allows users to delete
 > inherited aces and propagate new aces in the tree) this makes no difference.

all applications have to do is obey the individual acls. Applications
never have to consider inheritance implications, unless they are
trying to setup a specific inheritance structure themselves.

Also, servers don't have to be aware of this 'semi-dynamic'
inheritance at all. It is purely a client construct, and is equivalent
to a tacky little LD_PRELOAD that runs chmod -R on a tree when you
change some permissions.

The wording can easily mislead. Some people might assume that "applied
at the time the ace is set" implies it is atomic, or at least
quick. In fact it is very much non-atomic, and can take a very long
time to propogate on a large tree (the client has to do manually
findfirst/findnext calls and recurse itself).

It really surprised me when I found this. I couldn't believe that this
was how the famed 'dynamic' inheritance of w2k3 ACLs worked!

Cheers, Tridge

---

From: [email-masked] (Christoph Klein)
Date: Tue, 14 Mar 2006 11:45:42 +0100

> http://wiki.linux-nfs.org/index.php/ACLs#The_ACL_Interoperability_Problem
Perhaps you can add a link to http://sourceforge.net/projects/ngacl on
your page, as a first try to address these issues on linux.

christoph

---

From: [email-masked] (Christoph Klein)
Date: Tue, 14 Mar 2006 12:59:30 +0100

Chris

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 27 Mar 2006 17:39:26 -0600

> Connectathon the other week, and I just wanted to post some kind of

[ snip big summary ]

I would like to thank Bruce for summarizing the discussion and bringing
it back to the WG alias.  Would also like to thank those that participated
in the discussion that followed.

Given that, there are elements of this thread of discussion that have
occurred on the NFSv4 WG alias before and to be honest, I have grown
weary.  I said as much in last week's WG meeting and suggested
a general course of action to avoid covering the issues again in the future.

In the NFSv4.1, we have included an expanded section describing the
NFSv4 ACLs.  This should be reviewed to ensure that we have a complete
description and agreement on the interpretations that have been drawn
from that.

Second, the NFSv4 WG will pursue 2 or 3 documents that will be
destined to be published as Information RFCs.  The first will be
a discussion of the mapping of the posix draft ACLs to/from the
NFSv4 ACLs.  This document has existed in the past and has been
dormant for some period.  It will be updated and republished and
reviewed by the working group.  The second document will be
a portion of the personal internet draft submitted by Sam Falkner
and Lisa Week.  That document was split such that the NFSv4 ACL
discussion was included in the NFSv4.1 document as mentioned above.
There was another section to the document that discussed the issues
of posix API behavior in the face of ACLs and specifically NFSv4 ACLs.
We have owners for those two documents.

Another potential set of documents would discuss the multi-protocol
filer environment (mixing NFSv4 and SMB ACLs) and then NFSv4 ACLs
in a SMB environment (similar to the posix API discussion).  We may
have an owner for this as well but will await confirmation.

Again, thanks for the input so far and please contribute to these
upcoming documents either directly or by review.

Spencer