Puppet and Windows ACLs (Access Control Lists)

[Rob Reynolds]

tl;dr: Windows manages permissions in a way that doesn't always translate well to mode. We're putting together a solution for this. Jump in the discussion.

I wanted to get this conversation started. We've put a lot of thought into how the model should look and focused on ease of use up to more advanced scenarios.

However I don't feel that what we have is complete. If you are familiar with Windows, we'd love to get your feedback. If you are not familiar with Windows, we'd still love to get your feedback.

A couple of notes to start it off:

1. This is currently planned to be a module on the forge.

2. We have some changes to make to core puppet to better enable handing windows permissions (changes around how mode is applied on Windows now when not explicitly specified).

3. We tried to map somewhat close to the way Windows ACLs/DACLs/ACEs work.

4. We've also attempted to leave room for future expansion or application on POSIX systems. Note: this is not a primary goal, so unless there is a design consideration on the model, it's probably not something we will approach with this current effort.

The format could look something like the following:

acl { 'c:/windows/temp/tempfile.txt':
  ensure => present,
  permissions => {
    'Administrators' => ['full']
    'bob' => ['mwrx'],
    'SomeDomain\Lisa' => [x10000000,'allow','inherit','one_level'],
    'S-5-1-18' => ['wrx','deny','inherit_objects_only','inherit_only']
  },
}

acl { 'c:/windows/temp/locked_dir':
  ensure => exact,
  permissions => {
    'Administrators' => ['full']
  },
}

Before you have an opportunity to look at the proposal and comment on specifics, how self-documenting is the above model?  What would you add or remove?

--

Rob Reynolds

Developer, Puppet Labs

Join us at PuppetConf 2014, September 23-24 in San Francisco

[Klavs Klavsen]

Den fredag den 25. oktober 2013 22.10.40 UTC+2 skrev Rob Reynolds:

tl;dr: Windows manages permissions in a way that doesn't always translate well to mode. We're putting together a solution for this. Jump in the discussion.

I wanted to get this conversation started. We've put a lot of thought into how the model should look and focused on ease of use up to more advanced scenarios.

However I don't feel that what we have is complete. If you are familiar with Windows, we'd love to get your feedback. If you are not familiar with Windows, we'd still love to get your feedback.

A couple of notes to start it off:

1. This is currently planned to be a module on the forge.

 

2. We have some changes to make to core puppet to better enable handing windows permissions (changes around how mode is applied on Windows now when not explicitly specified).

IMHO it should be possible to leave out mode (especially when ones declare an acl instead) - and puppet should NOT care about mode (as in shouldn't try to set it as it does not, and breaks windows permissions).

 

3. We tried to map somewhat close to the way Windows ACLs/DACLs/ACEs work.

 

4. We've also attempted to leave room for future expansion or application on POSIX systems. Note: this is not a primary goal, so unless there is a design consideration on the model, it's probably not something we will approach with this current effort.

acl should most definetely be applicable for any unix filesystem mounted with ACL support :)
 

The format could look something like the following:

acl { 'c:/windows/temp/tempfile.txt':
  ensure => present,
  permissions => {
    'Administrators' => ['full']
    'bob' => ['mwrx'],
    'SomeDomain\Lisa' => [x10000000,'allow','inherit','one_level'],
    'S-5-1-18' => ['wrx','deny','inherit_objects_only','inherit_only']
  },
}

acl { 'c:/windows/temp/locked_dir':
  ensure => exact,

That one throws me.. ensure exact? I would expect 'exact' to be the same as 'present' (which in thise case is kinda odd wording- but so is exact.. who would want puppet to "almost" ensure something?

[jcbollinger]

On Monday, October 28, 2013 2:55:32 AM UTC-5, Klavs Klavsen wrote:

Den fredag den 25. oktober 2013 22.10.40 UTC+2 skrev Rob Reynolds:

[...]

The format could look something like the following:

acl { 'c:/windows/temp/tempfile.txt':
  ensure => present,
  permissions => {
    'Administrators' => ['full']
    'bob' => ['mwrx'],
    'SomeDomain\Lisa' => [x10000000,'allow','inherit','one_level'],
    'S-5-1-18' => ['wrx','deny','inherit_objects_only','inherit_only']
  },
}

acl { 'c:/windows/temp/locked_dir':
  ensure => exact,

That one throws me.. ensure exact? I would expect 'exact' to be the same as 'present' (which in thise case is kinda odd wording- but so is exact.. who would want puppet to "almost" ensure something?

I think Klavs has an excellent point there.  After some consideration, I think I understand what 'exact' is supposed to mean -- that the ACL should contain the specified entries and no others -- but the perceived need for such a thing suggests that the proposed model is too high level.  Instead of wrapping everything up into a single Acl resource type, I think you need a resource type for individual ACEs.  That would also allow you to ensure some specific entries present in and some others absent from the same ACL, without requiring that all wanted entries be enumerated.  A model inspired by the Concat module might be suitable.

Note too that in the Puppet universe, a parameter or value indicating that unmanaged resources should be removed is conventionally spelled "purge" or "purged".

Additionally, although POSIX ACEs are unordered, it is my understanding that the order of ACEs within a Windows ACL is significant.  If that is indeed correct then I don't see how the proposed model accounts for it.


John

[Rob Reynolds]

On Mon, Oct 28, 2013 at 2:55 AM, Klavs Klavsen <kl...@enableit.dk> wrote:

Den fredag den 25. oktober 2013 22.10.40 UTC+2 skrev Rob Reynolds:

tl;dr: Windows manages permissions in a way that doesn't always translate well to mode. We're putting together a solution for this. Jump in the discussion.

I wanted to get this conversation started. We've put a lot of thought into how the model should look and focused on ease of use up to more advanced scenarios.

However I don't feel that what we have is complete. If you are familiar with Windows, we'd love to get your feedback. If you are not familiar with Windows, we'd still love to get your feedback.

A couple of notes to start it off:

1. This is currently planned to be a module on the forge.

 

2. We have some changes to make to core puppet to better enable handing windows permissions (changes around how mode is applied on Windows now when not explicitly specified).

IMHO it should be possible to leave out mode (especially when ones declare an acl instead) - and puppet should NOT care about mode (as in shouldn't try to set it as it does not, and breaks windows permissions).

Yes, this is what I was referring to.

[Rob Reynolds]

On Mon, Oct 28, 2013 at 8:42 AM, jcbollinger <John.Bo...@stjude.org> wrote:

On Monday, October 28, 2013 2:55:32 AM UTC-5, Klavs Klavsen wrote:

Den fredag den 25. oktober 2013 22.10.40 UTC+2 skrev Rob Reynolds:

[...]

The format could look something like the following:

acl { 'c:/windows/temp/tempfile.txt':
  ensure => present,
  permissions => {
    'Administrators' => ['full']
    'bob' => ['mwrx'],
    'SomeDomain\Lisa' => [x10000000,'allow','inherit','one_level'],
    'S-5-1-18' => ['wrx','deny','inherit_objects_only','inherit_only']
  },
}

acl { 'c:/windows/temp/locked_dir':
  ensure => exact,

That one throws me.. ensure exact? I would expect 'exact' to be the same as 'present' (which in thise case is kinda odd wording- but so is exact.. who would want puppet to "almost" ensure something?

I think Klavs has an excellent point there.  After some consideration, I think I understand what 'exact' is supposed to mean -- that the ACL should contain the specified entries and no others -- but the perceived need for such a thing suggests that the proposed model is too high level.  Instead of wrapping everything up into a single Acl resource type, I think you need a resource type for individual ACEs.  That would also allow you to ensure some specific entries present in and some others absent from the same ACL, without requiring that all wanted entries be enumerated.  A model inspired by the Concat module might be suitable.

Yes, this is indeed the area I was talking about that is needing more discussion. 

Splitting to a resource type for individual ACEs might be beneficial, but it also might be too verbose. For an absent ACE, I was considering `'bob' => []`.

The actual idea on ensure present versus exact (versus the other values) and Windows is that there are some inherited ACEs. When you specify permissions, you are specifying explicit ACEs and not inherited ACEs.

Would you always want to specify 'SYSTEM' and 'Administrators' in every acl or would that get old having to specify for items that are already going to be inherited? Are there other permissions that may already be there that you don't want to manage? That's really where the difference between present and exact came about. In a way of saying, I want to manage this particular set of permissions, plus any that are already inherited (idea of present). 

If you don't want to have inherited permissions on a particular ACL, that's where exact would come in.

 

Note too that in the Puppet universe, a parameter or value indicating that unmanaged resources should be removed is conventionally spelled "purge" or "purged".

I think I understand, but let me see if I have this correctly:

acl { 'c:/windows/temp/locked_dir':
  ensure => purge,
  permissions => {
    'Administrators' => ['full']
  },
}

Any value not in the list above would be purged, correct? Unfortunately, I avoided this convention specifically due to how it self documents. It appears to be ensuring that the specified permission is removed, even though those that understand the convention know this is not the case.

 

Additionally, although POSIX ACEs are unordered, it is my understanding that the order of ACEs within a Windows ACL is significant.  If that is indeed correct then I don't see how the proposed model accounts for it.

Yes, you are correct. We're talking about this and whether the module should reorder appropriately for the order in some cases. We've talked about an array instead of a hash for ACEs.

 

John

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To post to this group, send email to puppet...@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

[Joaquin Menchaca]

What is most important to me is to have the ability to set ACLS on existing resources, such as file, service, and registry (and other objects). 

For now, it would be an immediate boon to apply the, oh so ugly, SDDL for a given resource, like a service.  Later, we can have an SDDL builder, that has some comfortable readable language, ala subinacle styled ACEs, that builds the SDDL that will be applied to the attribute level.  This can be similar to how ERB is used in the content("stuff").

I think if you take this approach, you avoid gross complexity of trying to merge how Windows works and how Puppet works, and avoid feature-scope creep.  It also gives the opportunity to add immediate value to existing puppet, and and more robust features later. 

If a particular resource that needs an ACL applied, such as certificate store or active directory OU, one needs to implement an actual resource for that type in PuppetForce.  If you have ACL resource modifying various objects, it will get overly complex, and you are just re-implementing the wheel as far as existing resources already, and you are breaking the whole model.  You'll be doing an anti-pattern for Puppet, and making a lot of future hurt, especially from the crowd that may bicker that Puppet should work like Windows...

By having an attribute for the SDDL, one can manage resources in the scope of how puppet currently managers resources, rather than having two cross scopes from opposing models of maintaining resources. 

Also, if there is a utility function, like like ERB's content(" "), then sys admins around the world will rejoice, as they no longer have to do nasties like this below:

sc sdset <SERVICE_NAME> "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;RPWPCR;;;S-1-5-21-2103278432-2794320136-1883075150-1000)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"

cacl c:\tools /s "D:PAI(D;OICI;FA;;;BG)(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;OICI;FA;;;SY)(A;OICI;FA;;;BU)"

setprinter \\”Print_Server_Name”\printer1 3 pSecurityDescriptor="O:BAG:DUD:(A;;LCSWSDRCWDWO;;;BA)(A;OIIO;RPWPSDRCWDWO;;;BA)(A;;SWRC;;;S-1-5-21-329599412-2737779004-1408050790-2604)(A;CIIO;RC;;;CO)(A;OIIO;RPWPSDRCWDWO;;;CO)(A;CIIO;RC;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;OIIO;RPWPSDRCWDWO;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;;SWRC;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;;LCSWSDRCWDWO;;;PU)(A;OIIO;RPWPSDRCWDWO;;;PU)"

[Rob Reynolds]

On Tue, Apr 29, 2014 at 5:45 PM, Joaquin Menchaca <joaqu...@gmail.com> wrote:

What is most important to me is to have the ability to set ACLS on existing resources, such as file, service, and registry (and other objects). 

We are starting with file, once we have that solid, we'll accept other target types - https://github.com/puppetlabs/puppetlabs-acl#acl-access-control-list

Can you read over that and see if you believe that we should do anything more complex with SDDLs?

 

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/aa39f4f3-a1aa-405f-8307-3c4f08fba2de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Rob Reynolds

Developer, Puppet Labs

Join us at PuppetConf 2014, September 23-24 in San Francisco

Register by May 30th to take advantage of the Early Adopter discount —save $349!

[Joaquin Menchaca]

I think to illustrate is better to make it more clear, let me get back to you on this, once I look it over.