Puppet 2.7 Windows File Permissions cause Permission Denied Errors

[phundisk]

I am trying to expand puppet to work for our windows servers and am noticing some weird permissions issues that are occurring.

I have a file resource being created that is a folder.  I set that folder to have full permission to user Administrator and a local windows group.  I set the mode to 0777 since I don't really care about security in this situation.  Puppet seems to create a 'Special' type windows permission for this directory and not the RWX regular windows permissions that I would expect it to use.  There are multiple applications that run within this created directory and thus the application needs permissions to stuff within the sub-directories of the created folder.  Each application runs as a separate user.  It seems that puppet is causing some permissions errors when we instantiate what I have below, even though we set the base permission of the directory to be fully open.  Is there any known bugs with puppet 2.7 and windows?  I know it is very limited in this version.  The client version is 2.7.20.  

group { "EaFarmGroup":

ensure => "present",

}

file { "C:\\MT4+EA-Farm":

ensure => 'directory',

owner => "Administrator",

group => "EaFarmGroup",

        mode => '0777',

}

_____________________________________________________

This email and any files transmitted with it are confidential and intended solely for the addressee.  If you received this email in error, please do not disclose the contents to anyone; kindly notify the sender by return email and delete this email and any attachments from your system.

© 2011 Currensee Inc. is a member of the National Futures Association (NFA) Member ID 0403251 | Over the counter retail foreign currency (Forex) trading may involve significant risk of loss. It is not suitable for all investors and you should make sure you understand the risks involved before trading and seek independent advice if necessary. Performance, strategies and charts shown are not necessarily predictive of any particular result and past performance is no indication of future results. Investor returns may vary from Trade Leader returns based on slippage, fees, broker spreads, volatility or other market conditions.

Currensee Inc | 54 Canal St 4th Floor | Boston, MA 02114 | +1.617.624.3824

[Josh Cooper]

Hi Alex,

If you don't care about permissions, you can just omit the mode property.

The owner should receive Full Control, but the group and other will
always receive less than that, e.g. they shouldn't get WRITE_DAC. For
example,

C:\work\puppet>envpuppet puppet resource file c:/blarg5
ensure=directory owner=Administrator group=Administrators mode=0777
notice: /File[c:/blarg5]/ensure: created
file { 'c:/blarg5':
ensure => 'directory',
group => 'S-1-5-32-544',
mode => '777',
owner => 'S-1-5-21-2397885826-1833024046-1055597067-500',
}

C:\work\puppet>icacls c:\blarg5
c:\blarg5 BIZARRO\Administrator:(F)
BUILTIN\Administrators:(RX,W,DC)
Everyone:(RX,W,DC)
CREATOR OWNER:(CI)(IO)(F)
CREATOR GROUP:(CI)(IO)(RX,W,DC)
CREATOR OWNER:(OI)(IO)(R,W,D,WDAC,WO,DC)
CREATOR GROUP:(OI)(IO)(R,W,DC)

So the owner is getting full control.

But I have seen that when puppet creates a file with mode 07xx, the
owner doesn't get FILE_DELETE_CHILD (really it should so that the
owner's permission is listed as Full Control instead of Special), but
it doesn't "hurt" anything, since that permission has no meaning for
files.

If you're still seeing the issue with directories, can you icacls on
the directory. Also do you get different results depending on whether
you're running puppet interactively as an Administrator vs running
puppet as LocalSystem?

Josh

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/3h1aSJvCNKgJ.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.



--
Josh Cooper
Developer, Puppet Labs

[phundisk]

[phundisk]

So I just tried to run as local system and administrator, no difference in terms of the permissions it created from looking at icalc.

I did a small modification to my class to see if it would help my issues.  Below I have a very detailed description of everything that is going on.

file { "C:\\MT4+EA-Farm":

ensure => 'directory',

owner => "EaFarmGroup",

        mode => '0777',

        recurse => true,

}

c:\mt4+ea-farm - permissions look good here, eafarmgroup has the "full" permissions.

c:\mt4+ea-farm\assigned - permissions look good here, eafarmgroup has "full"

I launched our application, which creates a subdirectory under assigned.  This process was launched from user1 who is in the eafarmgroup

c:\mt4+ea-farm\assigned\folder1 - For this directory, I see some weird permissions and I think this is where the root of my puppet/windows issues occur.  I see the 'user1' has "full" permissions, and that the group 'none' was added with rx,w,dc.  If i re-rerun puppet though, these issues will be fixed due to the recurse parameter.  I am thinking, it might make sense to set in puppet, ensure => directory, and just have setting the permissions be a manual step, though I hate doing things manually.

Any thoughts on this?

On Monday, December 10, 2012 4:09:36 PM UTC-5, phundisk wrote:

[Josh Cooper]

Hi Alex,

On Tue, Dec 11, 2012 at 7:29 AM, phundisk <alex.f...@currensee.com> wrote:
> So I just tried to run as local system and administrator, no difference in
> terms of the permissions it created from looking at icalc.
>
> I did a small modification to my class to see if it would help my issues.
> Below I have a very detailed description of everything that is going on.
>
> file { "C:\\MT4+EA-Farm":
> ensure => 'directory',
> owner => "EaFarmGroup",
> mode => '0777',
> recurse => true,
> }
>
> c:\mt4+ea-farm - permissions look good here, eafarmgroup has the "full"
> permissions.
> c:\mt4+ea-farm\assigned - permissions look good here, eafarmgroup has "full"
>

When puppet creates the directory, it creates CREATOR_OWNER and
CREATOR_GROUP access control entries which are inherited by dir/files
created within the parent directory. For example, if I create the
directory using puppet:

C:\work\puppet>envpuppet puppet resource file c:/mydir
ensure=directory owner=Administrators mode=0777
notice: /File[c:/mydir]/ensure: created
file { 'c:/mydir':
ensure => 'directory',
mode => '777',
owner => 'S-1-5-32-544',
}

And then dump the ACL:

C:\work\puppet>icacls c:\mydir
c:\mydir BUILTIN\Administrators:(F)
BIZARRO\Domain Users:(RX,W,DC)

Everyone:(RX,W,DC)
CREATOR OWNER:(CI)(IO)(F)
CREATOR GROUP:(CI)(IO)(RX,W,DC)
CREATOR OWNER:(OI)(IO)(R,W,D,WDAC,WO,DC)
CREATOR GROUP:(OI)(IO)(R,W,DC)

In my case, I'm running as Administrator, and my default group is
"Domain Users". Notice that puppet also creates IO (inherit only)
access control entries for CREATOR_OWNER & GROUP. There is one set for
subdirectories (CI => container inherit) and one set of files (OI =>
object inherit). These are special access control entries in that
those permissions are applied to objects created within the parent
directory based on the DACL specified at creation time. If none is
specified, e.g. NULL security descriptor is passed to CreateFile, then
it applies the creator's default DACL, which varies based on the user,
version of windows, etc.

> This process was launched from user1 who is in the eafarmgroup
> c:\mt4+ea-farm\assigned\folder1 - For this directory, I see some weird
> permissions and I think this is where the root of my puppet/windows issues
> occur. I see the 'user1' has "full" permissions, and that the group 'none'
> was added with rx,w,dc.

The default DACL for user1 is likely None. When user1 creates folder1,
the following inherit only access control entries from the parent
directory are applied to it:

CREATOR OWNER:(CI)(IO)(F)
CREATOR GROUP:(CI)(IO)(RX,W,DC)

> If i re-rerun puppet though, these issues will be
> fixed due to the recurse parameter. I am thinking, it might make sense to
> set in puppet, ensure => directory, and just have setting the permissions be
> a manual step, though I hate doing things manually.

Since you didn't specify a group in your puppet manifest, puppet is
likely removing the access control entry that granted (RX,W,DC) to
None.

>
> Any thoughts on this?

You could specify "group => none" in your manifest so that the
permissions converge without requiring another puppet run. But that
only works if the default DACL for all of your users is None, and it
may not be.

Instead, I would set the permissions on the directory, specifying the
owner, group and mode, but don't recurse. Any dir/file created later,
not by puppet, will have permissions based on the default DACL of the
user that created it, plus whatever inherited access control entries
from the puppet-managed directory.

Note that the None group cannot contain any members, so no one can get
access to folder1 based on the None access control entry.

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/puppet-users/-/6qGKBZoubFcJ.

>
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

Josh