Subject: RE: [nfsv4] Windows/NFSv4 ACL interoperability

From: "Yoder, Alan" <[email-masked]>
Date: Mon, 13 Mar 2006 16:04:00 -0800

I don't have time for a detailed discussion today,
but will note the following.

During the NFVv4 ACL spec writeup, I questioned the
lack of ordering requirements for ALLOW and DENY.
Carl Beame demonstrated to my satisfaction that 
Windows NT servers did not at that time enforce
any such thing, and that the requirement is (was?)
entirely client-side in Windows.

I hope this is germane to the discussion; apologies
if not.

Alan

===============================================================
Alan G. Yoder                                    [email-masked]
Technical Staff                           
Network Appliance, Inc.                            408-822-6919
===============================================================  

> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]] 
> Sent: Sunday, March 12, 2006 2:41 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: [nfsv4] Windows/NFSv4 ACL interoperability
> 
> 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_Interoperabil
> ity_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-0
> 0.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/sfu
> 3perm.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_Ov
erview/Concepts/c> hapter_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
> 

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 13 Mar 2006 22:19:22 -0500

> entirely client-side in Windows.

Yeah, that's my understanding too.

So the problem is just with stuff like a posix user setting a bunch of
long carefully crafted ACLs and then a Windows user not being able to
read them and blowing them away in an attempt to modify them.

To a certain extent that kind of problem may be unavoidable.  But we may
have some control over how common it is and how gracefully we fail.

--b.

---

From: [email-masked]
Date: Tue, 14 Mar 2006 19:52:24 +1100

Volker,

 > The one thing that I'd have to verify by experimentation is
 > whether is Windows walks the ACL twice: Once only looking
 > for negative entries and once for the positive ones. Reading
 > the user-level docs it seems that negative ones are looked
 > at first, but this might be because all GUIs order them.

I developed the sec_access_check() function in
libcli/security/access_check.c code in Samba4 pretty carefully, and
I'm fairly confident it is accurate, in terms of matching what w2k3
does. It walks the ACL just once. Note that it is not the same as any
published docs I have found (in particular the ordering of the special
case tests at the top of the function are different to all docs I have
seen).

The RAW-ACLS test in Samba4 smbtorture is quite a useful test case for
this stuff too.

Cheers, Tridge

---

From: Volker Lendecke <[email-masked]>
Date: Tue, 14 Mar 2006 08:51:18 +0100

Volker

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 27 Mar 2006 18:10:28 -0600

> > entirely client-side in Windows.
             ^^^^^^^^^^^^^^^^^^^^^^

> Yeah, that's my understanding too.

The Windows ordering is done in the GUI/libraries, not in the kernel.

Cygwin has exploited this in the past to emulate POSIX modes much as one
might use this to emulate POSIX Draft ACLs.

> have some control over how common it is and how gracefully we fail.

I agree.  The right solution is to move away from POSIX Draft ACLs.

Maintaining two ACLs, for example, doesn't help since that can lead to
conflicting authorizations depending on how one accesses a file, and how
would conflicts on ACL change operations be handled?

The best interim option, I think, is to silently ignore the problem on
ACL change operations and accept whatever ACE order the client requests.

Nico
--