Issue #13490 has been updated by Josh Cooper. Status changed from Unreviewed to Rejected
Hi Michael, Windows XP is not an officially supported platform for puppet. With that said, the behavior you reported (files are only accessible by the creator) is a result of differences in the default DACL on Windows XP vs 2003 and later. In XP, securable objects (files, etc) created by members of the local administrators group are owned by the user by default. In 2003 and later, these objects are owned by the administrators group, which implicitly grants access to the system account. This page describes the differences in the default DACL in more detail <http://support.microsoft.com/kb/318825/en-us>. As for why puppet is removing the access control entry for system, it's because puppet is just doing what it was told to do. For example, puppet's lib/puppet/defaults.rb defines the mode for the host private key. It's being told to only allow read/write access to the owner of the file: <pre> :hostprivkey => { :default => "$privatekeydir/$certname.pem", :mode => 0600, :owner => "service", :desc => "Where individual hosts store and look for their private key." }, </pre> Puppet does not currently support the ability to manage owner and group for file-based settings on Windows. So in the example above, we don't try to set owner to the 'service' user on Windows. But if we did support that, then I'd recommend setting those values appropriately for your system, e.g. :owner => 'Administrators' Supporting that would not be too difficult (now that we have the ability to chown and chgrp on Windows), though puppt has some hard-coded dependencies such as assuming the 'service' user is always root, assuming the owner is always a user and not a group. Feel free to file a feature request. ---------------------------------------- Bug #13490: Windows XP: Wrong permissions on etc\ssl and var\log\puppetd.log https://projects.puppetlabs.com/issues/13490#change-58836 Author: Michael Smith Status: Rejected Priority: Low Assignee: Category: windows Target version: Affected Puppet version: 2.7.12 Keywords: Branch: On Windows XP SP3, if you run the Puppet agent from Command Prompt, it creates etc\ssl and var\log\puppetd.log with permissions that don't allow access when the agent later runs as a service. I installed Puppet as a user with membership in the Administrators group. On Windows XP the C:\Documents and Settings\All Users\Application Data directory allows Full Control by SYSTEM, and this permission is normally inherited by subdirectories. When I run the Puppet agent as this user, it creates C:\Documents and Settings\All Users\Application Data\PuppetLabs\puppet\etc\ssl (directory) and C:\Documents and Settings\All Users\Application Data\PuppetLabs\puppet\var\log\puppetd.log (file). It breaks the permission inheritance and sets permissions as follows: <pre> etc\ssl: - owned by my user account, with Full Control - traverse, read attributes, read perms by Everyone - traverse, list, read, create, write, delete subfolders by Domain Users var\log\puppetd.log: - owned by my user account, with all perms except Full Control & Traverse - read attributes, read permissions by Everyone - list, read attributes, read permissions by Domain Users </pre> This doesn't allow access by SYSTEM, so the service can't write to puppetd.log nor access etc\ssl. The workaround is to 1) go to the advanced security properties on C:\Documents and Settings\All Users\Application Data\PuppetLabs and check "Replace permission entries on all child objects" to override the permissions, and apply. 2) Go to the Owner tab, ensure the owner is set to the Administrators group, and check "Replace owner on subcontainers and objects", and apply. The service can then access the files. I'm not sure of this, but I guess SYSTEM is a member of Administrators. Puppet touches the permissions of etc\ssl and var\log\puppetd.log on every run. It changes the permissions to: <pre> etc\ssl: - owned by Administrators, with Full Control - traverse, read attributes, read perms by Everyone - traverse, list, read, create, write, delete subfolders by Domain Users var\log\puppetd.log: - owned by Administrators, with all perms except Full Control & Traverse - read attributes, read permissions by Everyone - list, read attributes, read permissions by Domain Users </pre> It seems that puppet gives the current owner permissions to access the files, but doesn't make sure the current owner is the Administrators group. If I do part 1 of the workaround - fixing the perms, but not setting the owner to Administrators - puppet can access the files on the first run, but not on subsequent runs because it's taken permissions away from SYSTEM. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
