Puppet does not apply inheritable SYSTEM permissions to directories it manages on Windows under certain circumstances

To address https://projects.puppetlabs.com/issues/15559, https://github.com/puppetlabs/puppet/commit/b578ed48ac9585edb86b296e99f8aeeecc02fb4e was added so that in the cases where an owner / group / mode were specified that did not include SYSTEM, Puppet would re-add SYSTEM permissions. Since there is generally no reason to remove SYSTEM permissions, the previous behavior was problematic as it could prevent services (like Puppet itself) from accessing files and directories.

This was handled by setting NT AUTHORITY\SYSTEM:(F) on files and directories.

However, this approach was subtly flawed, when files or directories are written to a directory that had SYSTEM permissions re-added by Puppet. Since inheritance is not set with the re-added permissions, these new children would no longer have an ACE for NT AUTHORITY\SYSTEM:(F). The solution here is to ensure that the SYSTEM ace is instead set like NT AUTHORITY\SYSTEM:(F)(CI)(OI). This allows the SYSTEM permission to propagate to any newly created files or directories within the parent managed directory, by turning on container inheritance (for directories) and object inheritance (for files).

As it turns out, Puppet itself is affected by this flaw on the first run that it writes an agent's private key, public key and the ca cert when the agent is not run as SYSTEM (which is the case during acceptance tests that run as cygsrv or Administrator). With debug logging on, the settings catalog, which explicitly sets permissions on these files (via https://github.com/puppetlabs/puppet/blob/master/lib/puppet/defaults.rb#L709-L759), can be observed making changes to re-add missing SYSTEM permissions on the next Puppet run like:

[Debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/private_keys/lmugyz1yds193au.delivery.puppetlabs.net.pem]/mode: mode changed '4000640' to '0640'

[Debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/public_keys/lmugyz1yds193au.delivery.puppetlabs.net.pem]/mode: mode changed '4000640' to '0644'

[Debug: /File[C:/ProgramData/PuppetLabs/puppet/etc/ssl/certs/ca.pem]/mode: mode changed '4000640' to '0644'

Another affected area is the cache/client_data/catalog dir (client_datadir). Heavy-handed approaches have been employed like the one at https://github.com/puppetlabs/marionette-collective/blob/master/acceptance/tests/mco_puppet_powershell.rb#L77-L94 that remove the unmanaged directory written by cygsrv (and lacking SYSTEM permissions), so that a subsequent service run may recreate directories with appropriate permissions.