Issue #13490 has been updated by Josh Cooper.
Michael Smith wrote:
> > Puppet does not currently support the ability to manage owner and group for
> > file-based settings on Windows.
Sorry, what I mean is that file-based settings are settings that are contained
in `lib/puppet/defaults.rb` and refer to file & directories that puppet uses
internally, e.g. for storing its ssl keys, logs, etc. In this case, puppet does
not set the owner or group on Winows.
> > Supporting that would not be too difficult (now that we have the ability to
> > chown and chgrp on Windows),
Puppet does support managing owner & group for file resources that you define
in your manifests:
<pre>
file { 'c:/foo.txt':
ensure => file,
owner => 'Administrators',
group => 'None',
mode => 0700
content => '...'
}
</pre>
So now that we can have the 'mechanism' for changing owner & group for
arbitrary files, it would not be too hard to have puppet do the same for files
that it manages internally.
----------------------------------------
Bug #13490: Windows XP: Wrong permissions on etc\ssl and var\log\puppetd.log
https://projects.puppetlabs.com/issues/13490#change-58839
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.
