Subject: [nfsv4] ACL Design Team Meeting Minutes

From: Lisa Week <[email-masked]>
Date: Mon, 21 Aug 2006 15:53:58 -0600

Hi all,

Attached is the write up of the meeting minutes from the ACL Design Team 
meeting in Broomfield, CO held August 8 - 10, 2006.

There is a short set of AIs that came out of the meeting.  In order to 
track them, I will be creating issues in the Issue Tracker and will 
follow-up to this message when that is finished.

Thanks,
Lisa
Final consensus of the "ACL Design Team" was:
=============================================
* Continue with the design and text as specified in the file uploaded to
  Issue #93 named acl.txt
  (http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue93) and pursue
  an easier to determine mask (i.e. rather than relying on interpreting
  the access mask bits in DENY ACEs).

  The text in Issue #93 will be modified based on the review of the
  document in the meeting and will be provided to Spencer for inclusion
  in the next rev of the minor version draft due out on Aug 24/25, 2006.

  There was no decision made on how the easier to determine mask proposal
  would move forward.  This is still an open issue.  We will work toward
  a plan.

* The meaning of the mode attribute will not be changed from what it is
  in RFC3530.

* Both ACL proposals that were on the table are "POSIX compliant".

Summary of AIs:
===============
AI001: Sam to write proposal for automatic inheritance and send it to WG.
AI002: Sam and Lisa to make modifications to the ACL chapter as
       discussed in the meeting and provide the updated text to Spencer
       prior to August 24, 2006.
AI003: Lisa to research Windows behavior to see what needs to happen in
       order to determine how to specify what behavior we should
       specify when creating an object when just an ACL is given.
       Reflect result of research in the updates provided to Spencer.
AI004: Lisa to help come to consensus on whether or not we should
       change the MAY to a SHOULD in:    "Access mask bits other those listed
       above, appearing in ALLOW ACEs, MAY also be disabled." in Section
       1.4.1.1. -  "Setting mode and not ACL"
AI005: Team to determine how to present findings to the WG at Interim meeting
       in Sept.
AI006: Team to finalize the goals section of the ACL chapter.
AI007: Mario to deterimine if their ACL test suites for CIFS can be opened up.
AI008: Bruce to write proposed text for Section 1.3.1.1 - Server
       Considerations.  This is the NFSv4 access checking algorithm.

===============================
Meeting Minutes from 08/08/2006
===============================
Attendees:
Bruce Fields
Andreas Gruenbacher
Sam Falkner
Lisa Week
Mario Wurzl (Attended the Windows Compatibility and Interoperability portion)

Agenda for 08/08/2006:
10:00am - 10:05am: Agenda bashing...
10:05am - 10:15am: Summary of Connectathon discussion w/ Samba people (Bruce)
10:45am - 11:30am: Discussion about goals for the ACL section of NFSv4.1
    * What are the working group's goals?
    * How should the goals be documented?
    * How should the goals be tracked?
1:00pm - 3:00pm: Windows Compatibility and Interoperability
3:00pm - 5:00pm: POSIX Compatibility

Summary of Connectathon discussion w/ Samba people:
===================================================

1.) ACE Ordering
    1.) Never use denies if possible
    2.) If we must, try to put them at the start.

	Andreas: There are three sources of DENY ACEs: (a) explicit,
	user-provided ones, (b) ones created to prevent permissions
	from accumulating across POSIX file classes, (c) ones created
	to implement file masks. Considering (a), I think we don't want
	to disallow user-provided DENY ACEs. Considering (b), we cannot
	prevent all accumulation of permissions across file classes
	with only DENY ACEs at the start (without being more
	restrictive than we want to be): we may need some DENY ACEs
	between group class ALLOW ACEs and other class ALLOW ACEs.
	Considering (c), instead of adding DENY ACEs for masking, we
	could remove the denied mask bits from all ALLOW ACEs though.
	We don't want to do this for every mode SETATTR because a mode
	SETATTR could then never re-enable any temporarily disabled
	permissions. Ways around this would to implement masks at the
	server, or to add mask DENY ACEs and apply them before exposing
	the ACL to Windows.

    3.)  We should try to get away from the A, D, A, D, A, D ordering.
    4.) When windows does object inheritance they do a specific ordering.
	Source:  http://msdn.microsoft.com/library/en-us/secauthz/security/automatic_propagation_of_inheritable_aces.asp
	"Directly applied ACEs have precedence over inherited ACEs. The system
	implements this precedence by placing directly applied ACEs ahead of
	inherited ACEs in a discretionary access control list (DACL)."

	Andreas: So in my interpretation, you can have DADA sequences in Windows
	in situations like this:

	/dir		user1:ALLOW_WRITE:FILE_INHERIT_ACE:DENY
			user2:ALLOW_READ:FILE_INHERIT_ACE:ALLOW
	/dir/file	user1:ALLOW_WRITE:FILE_INHERIT_ACE/INHERITED_ACE:DENY
			user2:ALLOW_READ:FILE_INHERIT_ACE/INHERITED_ACE:ALLOW
			user1:ALLOW_READ::DENY
			user2:ALLOW_WRITE::ALLOW

2.) Windows does not allow the SIDs that correspond to OWNER@ and 
GROUP@ entities in effective ACEs.  Although, it does allow them in
inheritable (only?) ACEs.
	Andreas: This problem doesn't seem addressable on the NFSv4
	side to me:  Windows simply behaves like this. Samba must
	continue to map between the current owner and current owning
	group's ACEs and OWNER@ and GROUP@ ACEs with NFSv4 ACLs.

3.) Name mapping
    File can be owned by a group.
    
	Mario mentioned that this is not a problem that this working group
	needs to solve. That is completely a server side issue.  Bruce
	mentioned having someone document how to do it...

	Mario: I assumed that we were talking about the name to UID (or other
	internal representation) mapping, in which case I consider it a
	server implementation problem

	Andreas: The Samba people will come asking to store Windows SIDs in
	NFSv4 ACLs; it is not always possible to map a SID into a who@where
	string. Which answer can we provide to them? Do we want to devise a
	special syntax for ACE who values from namespaces outside of NFSv4?

	Design Team's Consensus:
	We shouldn't solve that problem right now.

4.) Inheritance - this is incredibly important to Windows.
    - Create time (Before Windows 2000 - this was the only inheritance type)
    - Automatic (missing)
	Andreas: We have three possible strategies with Automatic
	Inheritance at this point:  (a) leave them out of the NFSv4.1
	spec, (b) reserve the necessary bits and attributes but leave
	all the details to be clarified by a subsequent I-D to be
	written when we have enough implementation experience, (c) try
	to specify Automatic Inheritance in NFSv4.1. IMHO we won't have
	the time for (c), but people will start to implement this
	anyway, so (b) may be the lesser evil than (a) because
	implementations will at least not start implementing the same
	thing with different flags/attributes. Option (b) requires that
	we figure out how NFSv4 servers are supposed to interact with
	this extension, which currently does not seem to be clear.

	Design Team's Consensus:
	We should work towards a proposal and send it out the WG.  The
	working group will decide if it (or which portions of it)
	should be put into NFSv4.1.  Sam will write the text up.

Discussion about goals for the ACL section of NFSv4.1:
=====================================================

What are the working group's goals?
-----------------------------------
Goals (written on board):
Maintain Backwards compatibility
Clarified semantics (permission bits, etc.)
Enable POSIX compliance
Better Windows compatibility
    - automatic inheritance
    - use of DENYs

(My scribblings)
Mode bit synchronization
Clarifications of semantics of the access mask bits. (ACE4_DELETE_CHILD
/ ACE4_DELETE)
Recommending a default DENY on fall-through the ACL.
NFSv4.0 and NFSv4.1 compatibility
Enable POSIX compliance
    Andreas thinks we should change the meaning of the mode in
    RFC3530.  This will be discussed later.
Better Windows Compatibility
    (This is the Automatic Inheritance change and the use (or non-use)
    of DENY ACEs)

RFC3530 - Andreas thinks it is a bit incorrect with regard to
additional/alternate

Andreas: POSIX requires that after a chmod(2), the file permission bits
provide an upper bound to the permissions granted to any process.
RFC3530 does not specify that a mode SETATTR must have this behavior,
and this needs to be fixed. (Relevant related issues to this problem
are the mapping of ACEs to POSIX file classes, whether an ACL SETATTR
should be permitted to modify the mode attribute, and how a mode can be
computed from a given ACL.)

How should the goals be documented?
-----------------------------------
- Design team's consensus was that they should be in the
specification.  This will be done with the expectation that we make
sure the goals are not too specific, simple and able to be time
honored.

How should the goals be tracked?
--------------------------------
- Assess the interoperability at Bakeathons/Connectathons
- We need to have better test suites...

Specific Review of Goals section of the new ACL chapter (Bruce):
================================================================
Bullets saying "Reasonable semantics" are vague.
-  Bruce says to change it to: "If a server supports both ACL and
Mode.  Try to provide them in a way that doesn't conflict with POSIX
compliance."  There were dissenting opinions on this.

- Bruce said to add: "Don't allow the the permissions to be more
permissive than what would be given when setting the mode."  This was
agreed to be a good thing.
	Andreas: This formulation is still too unclear to me.

- Bruce said to remove: "It must be possible to implement a server such
that its clients can have POSIX compliant semantics."  There were
dissenting opinions on completely removing this.  Perhaps it needs to
be clarified.

	Andreas: The whole point of having the mode attribute is POSIX
	compliance IMO, so I would call anything in the specification
	that prohibits POSIX compliance a bug. The stated goal doesn't
	actually require any specific server implementation to be POSIX
	compliant, so the goal doesn't actually provide any value to
	clients.

- Andreas recommended adding: "If the NFS server supports the mode
attributes it should have POSIX semantics."  There were dissenting
opinions on this.  (What was the decision? - I believe it was to NOT
add this)

	Andreas: It would be really really nice if we could at least strongly
	suggest that servers that implement the mode attribute should do so in
	a POSIX compliant way. (And we'll clarify in NFSv4.1 what that means.)

	I see the problem that current NFSv4.0 implementations would
	need to change the implementation of the mode SETATTR
	operation. One thing to note is that NFSv4.0 implementations
	which implement NFSv4 ACLs on top of POSIX ACLs will
	automatically have POSIX compliant behavior.

* We will try to nail down (i.e. tweak wording, add and remove items,
etc.) the "Goals" section of the ACL chapter in NFSv4.1 during this
meeting.  This is a non-formal meeting deliverable.

Windows Compatibility and Interoperability
==========================================
Bruce re-hashed the discussion that was had in the morning session about the
Connectathon conversation.  (See above)

Mario commented that:
The server is in control of the inheritance at create time.
The client is in control of the inheritance after creation time.

Is automatic inheritance a worthy thing to pursue?  Yes.  There is
interest in adding the flags.  The EMC server does support the flags
INHERITED_ACE and SE_DACL_PROTECTED.  The server does not do anything
with the SE_DACL_PROTECTED flag, which is used only by clients when
propagating ACEs on a tree.
	Recap of the Consensus:
	We should work towards a proposal and send it out the WG.  The
	working group will decide if it (or which portions of it)
	should be put into NFSv4.1.  Sam will write the text up.

The question of what happens when you change a mode on the client was asked:
Mario: EMC keeps the ACEs that have gotten inherited from the client.
Throw away the ACEs that have been explicitly set.  And, write the ACL, but
don't propagate the changes downward.

Hard links and the inheritance problem with them:
[Open Issue] * Thought is that the last the last ACL set wins, but we need to
specify what this behavior is...

Bruce asked if inheritance propagates across Window's client mount
points.  The answer was we don't know.

How can we test our inheritance behavior?  Mario will check out if EMC
has CIFS tests that test inheritance.  See 08/09/2006 Minutes for
additional information.

Description of what EMC does for OWNER@ and GROUP@ entities:
Mario: Each owner and group ACE has a type flag, which indicates
whether the WHO field indicates the owner of the file or the
onwer-group. When a CIFS client reads the ACL, the SIDs of the owner
and owner-group are retuned to the client, and when a NFS v4 client
reads the ACL, the WHO field is translated to OWNER@ and GROUP@

Approaches for handling the setting of a mode when servers support both
mode and ACL:
1.) Masking
    a.) Add DENY aces for masking
    b.) New file attribute (mask attribute) which sets an upper bound
    on the ACL

    Andreas's argument for masking: When a file is being accessed via
    Windows applications (Explorer) on one client and by POSIX
    applications (chmod) on another client.  The interaction should be
    sane

    Mario: I am not aware of many cases where applications access the
    same file from Windows and UNIX/Linux. The only case I know of are
    some CAD applications that may access the file from clients using
    different protocols.  from my understanding, multiple protocol
    access is more common with user data.

    Andreas: Could it be that people try to avoid these kinds of
    interactions because they learned from past experience that strange
    things will happen otherwise (like a chmod overwriting an ACL that the
    user carefully created)? I am much in favor of trying very hard to
    avoid frustrating users. A mapping that will work really well when
    different systems interact is key here I believe.

    Consensus of the group: 
    The thought was that there was not much difference between the two
    use cases, therefore, we should work to make the interactions
    between the two systems as seemless as possible.

2.) Throw away all non-inherited ACES upon chmod (this approach is used
by EMC in order to avoid the complexity, but it was mentioned that this
requires the inherited flag...which NFSv4 does not have.)

When windows and POSIX applications interact: Andreas's goal: There is
a huge Windows install base.  We want to ensure that we can add UNIX
servers to the picture, and use Windows as well as POSIX applications
on the same files, and both will interact in a sane way.

Specific application that relies on the fact that posix mode is
upheld:  Linkers, compilers.

POSIX Compatibility
===================
Andreas had a set of slides explaining the POSIX definitions.  The slides are
attached.

* In Andreas' opinion, the definition of the NFSv4 is more specific
than the POSIX definition.

* Is there any text in POSIX that explains security? I don't know.

	Andreas: So IIRC the argument that lead to this question was
	that POSIX applications should not remove restrictions imposed
	on users by mechanisms not defined by POSIX itself by accident,
	such as by an unintended side-effect of chmod.  (POSIX does
	define that there may be additional and alternate file access
	control mechanisms and it defines which mechanisms this may be,
	but it doesn't define the mechanisms themselves.)

* A discussion on both of the ACL proposals and how they fit into being
POSIX compliant occurred.  The consensus at the meeting was that both
proposals are in fact POSIX compliant.
	- Because of coming to that consensus the next steps are to decide
	on which behaviors we want to have regarding mode writing through
	to the ACL.  Sam said that the goal is to not render existing Native
	POSIX-Draft implementations uncomplying, but to specify the behaviors
	that we *really* want to have with implementations
	- Also, still need to come to the final decision on what effect
	changing the mode has on the ACL.

===============================
Meeting Minutes from 08/09/2006
===============================
Attendees:
Sam Falkner
Lisa Week
Andreas Gruenbacher
Bruce Fields
Mario Wurzl (Attended the Windows Compatibility Follow-up portion)

Agenda for 08/09/2006:
9:00am - 11:30am: Review of the new ACL chapter text
1:00pm - 2:00pm: Windows Compatibility Follow-up and other misc. stuff
	(joined by  Mario at 1-2pm)
2:00pm - 5:00pm: Discussion about what additional documents may be
	pursued/needed and the plan for the existing ones.
        * NFSv4 to POSIX-draft ACL mapping (Bruce),
        * POSIX compliance with NFSv4 ACLs (?)
        * Windows interoperability with NFSv4 ACLs including documenting
        behaviors (i.e. how does dynamic inheritance really work) (?)
        * Dual protocol server capabilities (CIFS and NFSv4.x (?))

The start of the review of the new ACL chapter quickly touched on the most
contentious points and that was tabled in order to discuss the following:

Windows Friendly Ordering Discussion:
=====================================
Sam lead a discussion on how we could try for a more Windows friendly ordering upon setting of a mode (using the methods as currently specified in NFSv4.1):

1.) Delete DENY and ALLOW ACEs with who of O@, G@, E@
2.) Determine which ACEs are masks and delete them
3.) Determine new mask ACE DENY and ALLOW sections
4.) concat.

D0: OWNER@  [!USR & (GRP | OTH)]
A0: OWNER@  [USR & !GRP & OTH]   <--This would only be required in a
D1: GROUP@  [!GRP]                  situation where the mode being set
                                    is something like 707.
mask
old ACL
A1: OWNER@  [*USR]
A2: GROUP@  [*GRP]
A3: EVERYONE@  [*OTH]
inherited

------

So, how do we do the masks:
* We have a mask attribute
* We use DENY ACEs

Arguments against a mask attribute:
Windows servers (i.e. Hummingbird) will never be able to support a mask
attribute.  Therefore, the Hummingbird server would HAVE to use DENY
ACEs in order to get the mask behaviors.

Concerns about using DENY ACEs:
Bruce is (very) worried about parsing an ACL and trying to determine
which DENY ACEs are masks.

Bruce is able to accept the fact that we may have to play with DENY
ACEs....but is not able to accept the fact that this is our future
direction.  Bruce would like a mask outside of using the DENY ACEs.

When clients don't support masks (and don't request it) how does that
interact with clients that do support mask attributes?

Bruce:
We could just not expose the mask as an NFSv4 Attribute.  Have that be
an internal server side only attribute.  Then the server can do what it
needs to in the face of a setacl and multiple chmods.  Then the server
can choose whether to turn off bits or to use DENY aces in order to
effectively turn off bits.

Andreas argues that if you could provide the mask attribute to clients
then why wouldn't you...

Windows Compatibility Follow-up and other misc. stuff
======================================================
Mario said that they have framework that runs the tests for CIFS.  He
is looking into taking the tests outside of the framework and they will
see if they will be able to open those up.  He will keep this AI, but
doesn't see it happening until after the summer is over.

[Open Issue] Automatic inheritance and NFSv4 servers that don't know
about the "Inherited bit":
--------------------------------------------------------------------
How do you handle the case when an original ACL is set via CIFS (with
inherited bit set on those ACEs inherited), then a new ACL is set by
NFSv4 (via read, modify, write or something...)?  This has be problem
that the NFSv4 client will be turning off the inherited bit in any ACEs
that previously had it.  You can:

1.) Just allow the propagation of inheritance to happen as usual, but
you may have the problem of an ever growing ACL in which the ACL will
have most of the ACEs in common.  This is especially in the case where
there are multiple operations over CIFS then NFSv4.  (Mario asked "why
can't servers just combine ACEs?"  (i.e. Two different ALLOW ACEs
defining different things, can't you just combine them into one ACE.))

2.) Turn on the SE_DACL_PROTECTED flag and don't allow propagation to
that file upon being set.

Mario asked: What problem trying to solve?  What about use cases...lets
try to get some specific use cases and solve the problem from
there...?

Discussion about keeping the mode and ACL in sync:
--------------------------------------------------
Mario said that making mode and ACL independent of each other is
against all of the customer feedback that they have been receiving.
Customers using multiple protocols generally understand the interaction
between modes and ACLs (?)

Andreas: can a server implement a switch to say which behavior to
implement?  (Meaning that mode either is or isn't independent of the
ACL.)  The answer was yes, the way the specification is written, a
server can do that if it so chooses.

Mario agrees with the way the current specification is written (i.e.
saying that the mode bits SHOULD write through to the ACL with regard
to O@, G@, E@ is good.  It allows us to recommend that the mode and ACL
stay in sync, but it leaves the capability open for doing what Andreas
wants to do (Andreas pointed out that this is what POSIX-draft ACLs
do...))

Misc. stuff:
-------------
Mario mentioned that "You should get the permissions you see and not more."

It was recommended that someone should present findings to the group at
the interim meeting...

Documents we view as being useful:
==================================
Question: Are any of these considered "out of scope" for the NFSv4 WG?

1.) Windows Behavior and Interoperability document:
- Bruce or Andreas may be willing to do it, but would be nice if
someone with intimate knowledge (like Hummingbird folks) would be
interested in documenting these things (i.e. The Windows friendly ACE
ordering, the automatic inheritance capabilies and the fact that it is
a client side behavior, etc.)

2.) The NFSv4 to POSIX-draft ACL mapping document
Planned for Informational RFC...

3.) NFSv4 ACLs and POSIX compliance
There are mulitple different ways to be POSIX compliant.  Would we want
multiple separate documents, one document ????  Andreas is planning on
finishing up the document that he has started.  He has mentioned that
he knows that there certain items that will be controversial, but  at
least it would be documented...

4.) CIFS and NFSv4 co-existence with regard to ACLs
There were some questions on how much this differed from the Windows
Behavior and Interoperability document.  The thought that is it should
at least be looked into to see if there are any issues that need to be
covered that wouldn't be covered by a Windows Behavior and
Interoperability document.  Andreas noted that Jeremy Allison would
have good input...

Review of NFSv4 to POSIX-draft ACL mapping
(draft-ietf-nfsv4-acl-mapping-04.txt)
==========================================
Problem:
Windows ACL editors will never be able to set an ACL that can be
accepted on a server with Native POSIX-draft ACLs if we use the mapping
as was described in draft-ietf-nfsv4-acl-mapping-03.txt.

Goals:
1.) Achieve Windows client interoperability when running against a
server with POSIX-draft ACL interoperability.

Want to map any NFSv4 ACL into a POSIX-draft ACL without violating any
guarantees.

Simple rules and observations:
* You can always reorder any two ALLOW ACEs (with any who values)
* You can always reorder any two DENY ACEs (with any who values)
* Switching the order of <ALLOW, DENY> to <DENY, ALLOW> would create an
acl that is less permissive than the original ACEs.
* Switching the order of <DENY, ALLOW> with <(masked) ALLOW, DENY>
would create an acl that is less permissible than the original ACEs

Example: Setting the following ACL:
ALLOW bfields write/append

Would end up setting the following ACL on the server:
ALLOW OWNER@ nothing
ALLOW bfields write/append
ALLOW GROUP@ nothing
ALLOW EVERYONE@ nothing

===============================
Meeting Minutes from 08/10/2006
===============================
Attendees:
Sam Falkner
Lisa Week
Andreas Gruenbacher
Bruce Fields
Mario Wurzl (Attended about 30 min of the morning session)

Agenda for 08/10/2006:
No formal agenda, but included a review of the review of the new ACL chapter
and discussion on the major contention points.

Discussion about the major contention points and some of the arguments
on both sides:

1.) Changing the ACL based on the mode bits being set (SETATTR of mode):

Option 1: Write through to the ACL
(Specified in the minor version draft)
----------------------------------------------
1.) Simpler mode application algorithm, if we insist on POSIX
first-match semantics and accept any NFSv4 ACL.
2.) RFC3530 compliant
	ZFS
3.) User Requests / Customers (Sun and EMC) have said that they want
the mode and ACL to say in sync.

Option 2: No-write through
(setting owner, owner_group and other will not happen upon SETATTR of mode)
------------------------------------
1.) If a sequence of chmod's is a no-op, it is also a no-op on the ACL.
2.) Gives POSIX draft ACL behavior:
	Linux ext2/3
	UFS on Solaris
	BSDs, IRIX, ...
3.) Better Linux Acceptance ?

Argument for no-write though:
1.) Write-through potentially elevates the permission on any "GROUP@" ACEs
in the ACL, thus introducing a security hole.
	Counter Argument:
	1.) The fact that a SETATTR of the mode changes the permissions
	of the owning group to what the mode being set says they should
	be is not a security hole.

	2.) If you really want to deny any capabilities to a specific
	group, you should NOT use a GROUP@ ACE because the value of the
	group that the GROUP@ can and will change with a chown to a different
	group (chgrp command)

2.) It is possible for chmod(stat()) simultaneously to elevate some
permissions (in the case where the mode calculation e.g.  maps
append-only to write), and to lower other permissions (in the case
where the original acl grants permissions to named users and groups
beyond those granted to GROUP@, and we're calculating the mode using
only GROUP@).

2.) How to calculate the mode bits from an ACL:

Option 1: They are an upper bound
Clarification: they are an upper bound on permissions granted to
the "group class", i.e., everyone that matches an entity in the ACL
other than OWNER@ or EVERYONE@.
------------------------------------------------
Only without write-through will it ensure that stat() returns the result of chmod()

Option 2: Based on u, g, o (OWNER@, GROUP@ and EVERYONE@ ACEs)
(Specified in minor version draft)
----------------------------------------
1.) With write-through ensures stat() after chmod() returns the mode
that was set.
2.) More NFSv2 Friendly ???????
	Bruce's Explanation: since NFSv2 uses mode bits to determine
	processes' right to access cached data, or to perform cached
	writes to a file, mode bits that represent permissions as more
	restrictive than they are may cause applications to see data
	that they shouldn't, or to fail in unexpected ways, whereas
	returning a smaller mode would result merely in reduced
	performance (because operations would unnecessarily be
	performed synchronously).

	*Neither* approach eliminates this possibility; e.g., with the
	second approach,

		OWNER@:rw:ALLOW
		bfields@:w:DENY
		GROUP@:rw:ALLOW

	will map to 660, but will deny bfields write even if bfields is
	in the file's group.  Note that this is also a perfectly legal
	posix draft acl, so the problem already exists on servers
	supporting those.

	However this kind of things seems slightly less likely with case #2.

	Complete solutions might involve:
		* Returning different (especially) modes to NFSv2
		clients.  Yuch.
		* Just telling people not to set ACLs (at least not
		overly weird ones) on filesystems accessed by NFSv2; or
		turn off NFSv2 entirely.
		* Implementing the v2 NFSACL protocol, which Trond
		tells me supports an ACCESS command?  (Just telling them to
		upgrade to v3 sounds easier to me.)

3.) Mario: Does it really matter? Hopefully mode bits as a permission model
will go away...NFSv4 has revived the thought that applications must
support ACLs...

Bruce: The problem for unix-y servers is that we'd like to introduce support
for NFSv4 ACLs into our local filesystems, for obvious reasons.  But we
can't introduce a flag day when we break mode bits and where everyone is
required to fix all applications, scripts, installers, etc., that depend
on mode bits to operate on the local filesystem.

3.) How do we mask

Option 1: Only with new protocol
--------------------------------------------
Simpler implementation
Less "guesswork" which would incorrectly weaken DENYs

Option 2: Use existing protocol (i.e. DENY ACEs)
(Specified in minor version draft)
------------------------------------------
Preserves more information in many cases

                  |  upper-bound         | U, G, O
------------------|----------------------|------------------
write-through     |     OK               | stat, chmod (changes the ACL)
------------------|----------------------|------------------
no write-through  |  without mask        | stat chmod (changes the ACL)
                     chmod, stat         | chmod, stat (gives different
                   (gives different mode)|              mode)

Bruce's preference on the major design points:
1.) Changing the ACL based on the mode bits being set (SETATTR of mode):
	Go with Option 1: Write through to the ACL
2.) How to calculate the mode bits from an ACL:
	Go with Option 2: Based on u, g, o (OWNER@, GROUP@ and EVERYONE@ ACEs)
3.) How do we mask
	Go with Option 1: Only with new protocol (*)

Bruce recommended proposing this via the Linux community and see what happens.
Andreas agreed.

Bruce: We tentatively plan to prototype an implementation of this [the
decided upon design for options 1 & 2] and see whether it's acceptable
to the wider community.  The above two changes increase the difference
between NFSv4 and POSIX draft ACL's, which may make acceptance more
difficult.

(*) This is the one Bruce will really fight for... and it is still an open
issue as to how to do it.

Review of the document:
=======================
Some small and other large changes were requested to be made to the
document by Bruce and Andreas.  See the attached document for comments
from Bruce and Andreas (search for "<comment>").

Remaining open issues on the document changes discussed:
1.) Section 1.1.  Goals
* There are multiple bullet items in the goals section that need the
text to be finalized.
2.) Section 1.4.1.1.  Setting mode and not ACL
* More discussion needs to go into the decision of whether or not we
should change the MAY to a SHOULD in:    "Access mask bits other those
listed above, appearing in ALLOW ACEs, MAY also be disabled."
Lisa has an AI to look into this.
3.) Section 1.4.3.  Creating New Objects
* Research into the Windows behavior needs to happen in order to
determine how to specify what behavior we should specify when creating
an object when just an ACL is given.  Lisa has an AI to look into this.

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

---

From: Lisa Week <[email-masked]>
Date: Tue, 22 Aug 2006 12:03:41 -0600

As mentioned before, I have created new and updated existing issues  
in the Issue Tracker in order to track the AIs and open issues from  
the meeting.  See the summary below.

Thanks,
Lisa

> Final consensus of the "ACL Design Team" was:

	Filed Issue #113 to track this.
	http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue113

> * Both ACL proposals that were on the table are "POSIX compliant".

	Filed Issue #112 to track this.
	http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue112

>        prior to August 24, 2006.

	Updated existing Issue #93.
	http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue93

>        Reflect result of research in the updates provided to Spencer.

	Filed Issue #114 to track this.
	http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue114

>        1.4.1.1. -  "Setting mode and not ACL"

	Filed Issue #115 to track this.
	http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue115

>        Considerations.  This is the NFSv4 access checking algorithm.

	The proposed changes have been integrated into the ACL text to be  
given to Spencer for inclusion in minor version draft *-06.  This is  
under the umbrella of Issue #93.