[nfsv4] Windows/NFSv4 ACL interoperability
Yoder, Alan
agy at netapp.com
Tue Mar 14 18:45:57 GMT 2006
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
===============================================================
Alan G. Yoder agy at netapp.com
Technical Staff
Network Appliance, Inc. 408-822-6919
===============================================================
> -----Original Message-----
> From: Peter Varga [mailto:Peter.Varga at hummingbird.com]
> Sent: Tuesday, March 14, 2006 7:05 AM
> To: Yoder, Alan; J. Bruce Fields; nfsv4 at ietf.org;
> samba-technical at lists.samba.org; Gardere_Daniel at emc.com;
> Roche_Francois at emc.com
> Subject: RE: [nfsv4] Windows/NFSv4 ACL interoperability
>
> 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:Peter.Varga at hummingbird.com]
> Sent: Tuesday, March 14, 2006 9:54 AM
> To: 'Yoder, Alan'; J. Bruce Fields; nfsv4 at ietf.org;
> samba-technical at lists.samba.org; Gardere_Daniel at emc.com;
> Roche_Francois at emc.com
> Subject: RE: [nfsv4] Windows/NFSv4 ACL interoperability
>
>
> 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:agy at netapp.com]
> Sent: Monday, March 13, 2006 7:04 PM
> To: J. Bruce Fields; nfsv4 at ietf.org; samba-technical at lists.samba.org;
> Gardere_Daniel at emc.com; Roche_Francois at emc.com
> 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 agy at netapp.com
> Technical Staff
> Network Appliance, Inc. 408-822-6919
> ===============================================================
>
> > -----Original Message-----
> > From: J. Bruce Fields [mailto:bfields at fieldses.org]
> > Sent: Sunday, March 12, 2006 2:41 PM
> > To: nfsv4 at ietf.org; samba-technical at lists.samba.org;
> > Gardere_Daniel at emc.com; Roche_Francois at emc.com
> > 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/S
> ecurity_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
> > nfsv4 at ietf.org
> > https://www1.ietf.org/mailman/listinfo/nfsv4
> >
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4
>
More information about the samba-technical
mailing list