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

From: Peter Varga <[email-masked]>
Date: Tue, 14 Mar 2006 09:53:58 -0500

No no no, let's clear up Windows ACLs once and for all (I hope):

Windows itself does not enforce or require any particular order for ACEs in
an ACL. That is, if you set an ACL with ACEs in some order, you can read it
back with all ACEs in the same order you set them. 

However, the order is extremely important when it comes to the evaluation of
the ACL (when determining if access to the file should be granted or
denied). Windows stops evaluating ACEs when the requested access is
explicitly granted or denied by the set of ACEs evaluated up to the current
ACE in the ACL. If the access evaluation falls through all ACEs, access is
implicitly denied:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/se
curity/how_dacls_control_access_to_an_object.asp

The end user doesn't know or care about ACEs, certainly not about their
order. They simply wish to set certain access rights to an object. That's
why it's explorer.exe's job to handle the ordering. Consequently,
explorer.exe will reorder an ACL by putting DENY entries first in order to
ensure access is denied when the user said it should be.

Peter

-----Original Message-----
From: Yoder, Alan [mailto:[email-masked]] 
Sent: Monday, March 13, 2006 7:04 PM
To: J. Bruce Fields; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: [nfsv4] Windows/NFSv4 ACL interoperability

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

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

---

From: Peter Varga <[email-masked]>
Date: Tue, 14 Mar 2006 10:05:04 -0500

If you click on the link at the bottom of the previous link I gave, you can
see the rules for how explorer handles inherited ACEs, allow and deny ACEs,
etc:

Order of ACEs in a DACL:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/secauthz/se
curity/order_of_aces_in_a_dacl.asp

1. All explicit ACEs are placed in a group before any inherited ACEs. 
2. Within the group of explicit ACEs, access-denied ACEs are placed before
access-allowed ACEs. 
3. Inherited ACEs are placed in the order in which they are inherited. ACEs
inherited from the child object's parent come first, then ACEs inherited
from the grandparent, and so on up the tree of objects. 
4. For each level of inherited ACEs, access-denied ACEs are placed before
access-allowed ACEs. 

Peter

-----Original Message-----
From: Peter Varga [mailto:[email-masked]] 
Sent: Tuesday, March 14, 2006 9:54 AM
To: 'Yoder, Alan'; J. Bruce Fields; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: RE: [nfsv4] Windows/NFSv4 ACL interoperability

Peter

-----Original Message-----
From: Yoder, Alan [mailto:[email-masked]] 
Sent: Monday, March 13, 2006 7:04 PM
To: J. Bruce Fields; [email-masked]; [email-masked];

Alan

---

From: [email-masked]
Date: Tue, 14 Mar 2006 03:42:07 -0500

Windows servers are walking ACL once, in the same order than the aces are
stored. However most client applications will expect that the aces are
sorted in the following order:

1) Explicit denied aces
2) Explicit allow aces
3) Inherited denied aces
4) Inherited allow aces

If the server doesn't return aces in that order then some applications will
get into trouble. For instance with explorer on windows NT I remember you
will then have a popup windows saying that there is something wrong so you
need to discard all aces or it will reorder them automatically. This is only
one example among others.
In general windows clients are not very tolerant with such things unlike
server side which is.

-----Original Message-----
From: Volker Lendecke [mailto:[email-masked]] On Behalf Of Volker
Lendecke
Sent: mardi 14 mars 2006 08:51
To: J. Bruce Fields
Cc: Yoder, Alan; Gardere, Daniel; [email-masked];
[email-masked]; Roche, Francois
Subject: Re: [nfsv4] Windows/NFSv4 ACL interoperability

On Mon, Mar 13, 2006 at 10:19:22PM -0500, J. Bruce Fields wrote:
> Yeah, that's my understanding too.

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.

Volker

---

From: [email-masked]
Date: Tue, 14 Mar 2006 11:44:13 -0500

Maybe, but one thing is sure is the API on the client side is checking the
structure. On the other side there is no interpretation of SIDs as long
their structure is correct, the sid could correspond to nothing but the
server accept it.

François

-----Original Message-----
From: Michael B Allen [mailto:[email-masked]] 
Sent: mardi 14 mars 2006 17:38
To: Roche, Francois
Cc: [email-masked]; [email-masked];
[email-masked]; Gardere, Daniel; [email-masked];
[email-masked]
Subject: Re: Windows/NFSv4 ACL interoperability

On Tue, 14 Mar 2006 06:36:10 -0500
[email-masked] wrote:

> I totally agree with Tridge, it is the client which is doing the
propagation
> down the tree not the server.
> Windows server is doing it only for file/directory creation.

Because security descriptors are not NDR encoded in various RPCs
I strongly suspect that they are not interpreted at all when simply
getting or setting them. They are just binary blobs. You get out
what you put in.

Mike

---

From: "Yoder, Alan" <[email-masked]>
Date: Tue, 14 Mar 2006 10:45:57 -0800

Just to be sure.  I assume you understand that
this means the server just needs to store the
ACL as it's given to it, and does not need to
enforce any ordering on the server side?

Alan

> Sent: Tuesday, March 14, 2006 7:05 AM
> To: Yoder, Alan; J. Bruce Fields; [email-masked]; 
> us/secauthz/se

---

From: Peter Varga <[email-masked]>
Date: Tue, 14 Mar 2006 14:22:19 -0500

Yea, generally, ACL construction is the client's job (except in the case
that the client tries to set the mode).

The ultimate objective is to to set up some new guidelines for NFSv4 ACLs in
order to prevents different types of clients from stepping all over each
other's ACLs :)

Peter

-----Original Message-----
From: Yoder, Alan [mailto:[email-masked]] 
Sent: Tuesday, March 14, 2006 1:46 PM
To: Peter Varga; J. Bruce Fields; [email-masked];

Alan

---

From: "Yoder, Alan" <[email-masked]>
Date: Mon, 27 Mar 2006 22:46:46 -0800

I'd guess that these threads also prove that POSIX ACLs 
are "not usable or easily understood even by people with 
research degrees in computer science." 

Your assertion regarding usable security--which I agree 
with at the philosophical level--is tough to validate by 
looking at market acceptance of the alternatives.

Alan

> From: Jeremy Allison [mailto:[email-masked]] 
> Sent: Monday, March 27, 2006 5:44 PM
> To: J. Bruce Fields; Yoder, Alan; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> On Mon, Mar 27, 2006 at 06:10:28PM -0600, Nicolas Williams wrote:
> > 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.
> > 
> > > 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.
> > 
> > I agree.  The right solution is to move away from POSIX Draft ACLs.
> 
> I disagree. POSIX draft ACLs are the right level of complexity for
> administrators to handle, and the Gnome and KDE GUI's are starting
> to be able to handle them. Windows ACLs are completely overdesigned
> and (as these threads adequately prove), not usable or easily 
> understood
> even by people with research degrees in computer science.
> 
> In terms of *usable* security (which IMHO is the only kind 
> that matters
> in the real world) POSIX ACLs are far superiour to Windows/NFSv4 ACLs.
> 
> Jeremy.
>