This is one scenario.

I believe there might be another scenario that leaves ACEs in an undesirable / unexpected order if managed ACEs aren't treated differently.

Another potential problem I see here is identifying which ACEs were previously managed.  Assume the following scenario.

I use a manifest to assign read / modify / execute to a given user.  I change my manifest to assign only read to the user, because I realized this was undesirable behavior.  I want to leave OS managed perms alone on the given path.

How does Puppet know that the old read / modify / execute ACE for the given user should be replaced with one that's read.  Given there can be multiple ACEs for a particular user, I think we need to address this somehow.  Maybe we allow only one deny and one allow ACE per user when Puppet manages DACLs (is this spec'd somewhere else in the armature)?

@joshcooper any other ideas on how we address preventing growth of the ACE list in the DACL over time?