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

[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.

[John Bollinger]

On Monday, October 28, 2013 11:54:25 AM UTC-5, Rob Reynolds wrote:

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' => []`.

But I think you need to do it.  Individual ACEs are for the most part what users want to manage.  In fact, consider that every file on an NTFS file system has an ACL no matter what.  How then do the standard ensure => 'present' and ensure => 'absent' even make sense for a resource type modeling the Acl itself?  Puppet can neither remove file ACLs nor create them; it can only manipulate them.  What you are ensuring absent or present are individual ACEs, so the model should attach the 'ensure' parameter to individual ACEs.

Moreover, if ACEs are separate resources then they can be decentralized.  Suppose, for instance, that a module managing some application needs to create a local user and grant that user permissions to access some system directory.  All is good if it can just drop an appropriate ACE in place, but it's an awful mess if the module needs to manage a whole ACL of a directory that doesn't belong to it.  Especially so when you consider that no resource can be declared more than once.

 

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.

So that's a little different than I thought, which you can construe as a clarity / intuitiveness problem if you wish to do so.

 

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?

No, I think the usual Puppet paradigm should apply: you specify only those resources and properties you want to manage, and Puppet leaves everything else alone.

This does highlight the possibility, though, that in addition to a resource type modeling ACEs, it may make sense to have a resource type modeling overall ACLs, too.  You could hang control of ACE inheritance there, and perhaps there are other properties to manage that apply to ACLs overall.

 

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.

Are you prepared to assume that there are not?  I think that would be unwise.

 

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']
  },
}

I think purging is something to consider, but now that I better understand the intention of 'exact', I think the two are separate.  Neither should be overloaded onto the ensure parameter, however.  Drawing on the File type as an exemplar of a container resource, I think this would be better:

acl { 'c:/windows/temp/locked_dir':
  inherit => false,
  purge => true
}

That says that the ACL for the specified file should not inherit ACEs from its parent's ACL, and that any unmanaged ACEs specified directly in it should be purged.  If no ACE resources are declared for the file then it will end up with no inherited ACEs and no ACEs of its own, either.  All four combinations of boolean 'inherit' and 'purge' values are potentially sensible.  Or actually there are six combinations, because if the 'inherit' parameter is not declared at all then Puppet should not modify ACL inheritance, thus that constitutes a separate value.

 
>> 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.

 

The needed order is whatever the user says it is, so for the module to "reorder appropriately", it has to offer some means for the user to declare that order.

So, an array then.  But an array of what, exactly?  Your hash values are already arrays themselves -- whose meanings are largely opaque to me, by the way -- so will you now have an array of arrays?  An array of hashes would be more self-documentary, but wait: those inner hashes now bear a strong resemblance to resource declarations.  Why was it, again, that you didn't want a separate resource type for ACEs?

Note, too, that whatever ordering mechanism you choose, you'll still have to decide how to deal with ordering relative to unmanaged ACEs.  Probably there's some room there for a smart implementation to figure something out, but there still ought to be a mechanism for the user to exert influence here.


John

[Rob Reynolds]

[...snip...]

 

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?

No, I think the usual Puppet paradigm should apply: you specify only those resources and properties you want to manage, and Puppet leaves everything else alone.

That's where I was leading to. :)

 

This does highlight the possibility, though, that in addition to a resource type modeling ACEs, it may make sense to have a resource type modeling overall ACLs, too.  You could hang control of ACE inheritance there, and perhaps there are other properties to manage that apply to ACLs overall.

Yes, agreed.

 

 

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.

Are you prepared to assume that there are not?  I think that would be unwise.

My assumption is that there would be permissions there that I would not want to manage so hoping other folks were also on that bus. :)

 

 

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']
  },
}

I think purging is something to consider, but now that I better understand the intention of 'exact', I think the two are separate.  Neither should be overloaded onto the ensure parameter, however.  Drawing on the File type as an exemplar of a container resource, I think this would be better:

acl { 'c:/windows/temp/locked_dir':

  inherit => false,
  purge => true
}

That says that the ACL for the specified file should not inherit ACEs from its parent's ACL, and that any unmanaged ACEs specified directly in it should be purged.  If no ACE resources are declared for the file then it will end up with no inherited ACEs and no ACEs of its own, either.  All four combinations of boolean 'inherit' and 'purge' values are potentially sensible.  Or actually there are six combinations, because if the 'inherit' parameter is not declared at all then Puppet should not modify ACL inheritance, thus that constitutes a separate value.

+1 I definitely like splitting ensure out for something more explicit. 

 

 
>> 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.

 

The needed order is whatever the user says it is, so for the module to "reorder appropriately", it has to offer some means for the user to declare that order.

So, an array then.  But an array of what, exactly?  Your hash values are already arrays themselves -- whose meanings are largely opaque to me, by the way -- so will you now have an array of arrays?  An array of hashes would be more self-documentary, but wait: those inner hashes now bear a strong resemblance to resource declarations.  Why was it, again, that you didn't want a separate resource type for ACEs?

Mostly because of resource explosion. https://gist.github.com/ferventcoder/7204591 - Note that it is 20 lines to say the same thing in 8 lines.  But is it the right answer? I think there is a happy medium here we should explore where one or both options could live.

 

Note, too, that whatever ordering mechanism you choose, you'll still have to decide how to deal with ordering relative to unmanaged ACEs.  Probably there's some room there for a smart implementation to figure something out, but there still ought to be a mechanism for the user to exert influence here.

Agreed.

 

John

--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/966af2a0-57df-41e6-a3b6-6180b62a23c6%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Rob Reynolds]

On Mon, Oct 28, 2013 at 2:59 PM, John Bollinger <john.bo...@stjude.org> wrote:

On Monday, October 28, 2013 11:54:25 AM UTC-5, Rob Reynolds wrote:

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' => []`.

But I think you need to do it.  Individual ACEs are for the most part what users want to manage.  In fact, consider that every file on an NTFS file system has an ACL no matter what.  How then do the standard ensure => 'present' and ensure => 'absent' even make sense for a resource type modeling the Acl itself?  Puppet can neither remove file ACLs nor create them; it can only manipulate them.  What you are ensuring absent or present are individual ACEs, so the model should attach the 'ensure' parameter to individual ACEs.

Moreover, if ACEs are separate resources then they can be decentralized.  Suppose, for instance, that a module managing some application needs to create a local user and grant that user permissions to access some system directory.  All is good if it can just drop an appropriate ACE in place, but it's an awful mess if the module needs to manage a whole ACL of a directory that doesn't belong to it.  Especially so when you consider that no resource can be declared more than once.

How would this model look? Noting that last items about a resource being declared more than once.

 

 [...snip...]

[Josh Cooper]

On Mon, Oct 28, 2013 at 12:59 PM, John Bollinger <john.bo...@stjude.org> wrote:

On Monday, October 28, 2013 11:54:25 AM UTC-5, Rob Reynolds wrote:

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' => []`.

But I think you need to do it.  Individual ACEs are for the most part what users want to manage.  In fact, consider that every file on an NTFS file system has an ACL no matter what. 

Not completely true. It can have a NULL ACL which grants permission to everyone.

 

How then do the standard ensure => 'present' and ensure => 'absent' even make sense for a resource type modeling the Acl itself?  Puppet can neither remove file ACLs nor create them; it can only manipulate them.  What you are ensuring absent or present are individual ACEs, so the model should attach the 'ensure' parameter to individual ACEs.

I'm not convinced ACEs should be separate resources, because they don't exist outside of an ACL. For example, consider properties that extend Puppet::Property::List, like the `groups` property for the `user` resource. You specify either the complete or minimum list of groups the user should belong to, as opposed to specifying each user's group and whether the user should be present/absent from the group.

 

Moreover, if ACEs are separate resources then they can be decentralized.  Suppose, for instance, that a module managing some application needs to create a local user and grant that user permissions to access some system directory.  All is good if it can just drop an appropriate ACE in place, but it's an awful mess if the module needs to manage a whole ACL of a directory that doesn't belong to it.  Especially so when you consider that no resource can be declared more than once.

 

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.

So that's a little different than I thought, which you can construe as a clarity / intuitiveness problem if you wish to do so.

 

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?

No, I think the usual Puppet paradigm should apply: you specify only those resources and properties you want to manage, and Puppet leaves everything else alone.

This does highlight the possibility, though, that in addition to a resource type modeling ACEs, it may make sense to have a resource type modeling overall ACLs, too.  You could hang control of ACE inheritance there, and perhaps there are other properties to manage that apply to ACLs overall.

Yes, the order of ACEs needs to be specified, and is one reason why permissions cannot be modeled solely using ACEs.

 

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.

Are you prepared to assume that there are not?  I think that would be unwise.

 

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']
  },
}

I think purging is something to consider, but now that I better understand the intention of 'exact', I think the two are separate.  Neither should be overloaded onto the ensure parameter, however.  Drawing on the File type as an exemplar of a container resource, I think this would be better:

acl { 'c:/windows/temp/locked_dir':

  inherit => false,
  purge => true
}

That says that the ACL for the specified file should not inherit ACEs from its parent's ACL, and that any unmanaged ACEs specified directly in it should be purged.  If no ACE resources are declared for the file then it will end up with no inherited ACEs and no ACEs of its own, either.  All four combinations of boolean 'inherit' and 'purge' values are potentially sensible.  Or actually there are six combinations, because if the 'inherit' parameter is not declared at all then Puppet should not modify ACL inheritance, thus that constitutes a separate value.

 
>> 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.

 

The needed order is whatever the user says it is, so for the module to "reorder appropriately", it has to offer some means for the user to declare that order.

So, an array then.  But an array of what, exactly?  Your hash values are already arrays themselves -- whose meanings are largely opaque to me, by the way -- so will you now have an array of arrays?  An array of hashes would be more self-documentary, but wait: those inner hashes now bear a strong resemblance to resource declarations.  Why was it, again, that you didn't want a separate resource type for ACEs?

Note, too, that whatever ordering mechanism you choose, you'll still have to decide how to deal with ordering relative to unmanaged ACEs.  Probably there's some room there for a smart implementation to figure something out, but there still ought to be a mechanism for the user to exert influence here.

Good point. Windows has a preferred ordering for inherited vs non, and allow vs deny ACEs, and we will need to take unmanaged ACEs into account.

--

Josh Cooper

Developer, Puppet Labs

[John Bollinger]

On Monday, October 28, 2013 4:05:47 PM UTC-5, Rob Reynolds wrote:

So, an array then.  But an array of what, exactly?  Your hash values are already arrays themselves -- whose meanings are largely opaque to me, by the way -- so will you now have an array of arrays?  An array of hashes would be more self-documentary, but wait: those inner hashes now bear a strong resemblance to resource declarations.  Why was it, again, that you didn't want a separate resource type for ACEs?

Mostly because of resource explosion. https://gist.github.com/ferventcoder/7204591 - Note that it is 20 lines to say the same thing in 8 lines.  But is it the right answer? I think there is a happy medium here we should explore where one or both options could live.

 

You achieve 8 lines vs. 20 by choosing a form that favors concision over clarity (and by your choice of where to break lines).  To represent ACEs as arrays as the example code does, the Acl type must make assumptions about the order of elements, and it must also either make inferences about the meaning of other elements based on their values (which is risky), or else limit which combinations of ACE properties can be modeled (which is unsatisfying).  As for self-documentation, where you started this discussion, the array representation of ACEs severely lacking.

A form more like this would be better in all those regards:

acl { 'c:/windows/temp/some_dir':
  inherit => true,
  purge => false,
  permissions => [
    { identity => 'bob', rights => 'modify', type => 'allow', inherit => 'all', propagate => 'all' },
    { identity => 'tim', rights => 'read_execute' }
  ],
}

At least the ACEs are then reasonably easy to interpret (by both humans and machines), but it's not much less verbose than a form with separate ACEs:

acl { 'c:/windows/temp/some_dir':
  inherit => true,
  purge => false,
}

ace {
  'bob/some_dir': identity => 'bob', file => 'c:/windows/temp/some_dir', priority => 1, rights => 'modify', type => 'allow', inherit => 'all', propagate => 'all';
  'tim/some_dir': identity => 'tim', file => 'c:/windows/temp/some_dir', priority => 100, rights => 'read_execute';
}

That's 8 non-empty lines as I wrote it, btw, if you really want to use such a metric (a token count would be less style-dependent).  Plus all the parameter values have simple types, which I think is a big usage win.

You mentioned concern about a "resource explosion", but I don't think the example actually went there.  Keep in mind that a major objective of the modern form of ACL inheritance was to minimize the number of distinct ACE objects in the system, keeping them toward the root of the tree, with the happy result that the main cases for Puppet to address involve relatively few ACLs and ACEs that actually need to be managed.


John

[John Bollinger]

On Monday, October 28, 2013 4:36:09 PM UTC-5, Josh Cooper wrote:

On Mon, Oct 28, 2013 at 12:59 PM, John Bollinger <john.bo...@stjude.org> wrote:

But I think you need to do it.  Individual ACEs are for the most part what users want to manage.  In fact, consider that every file on an NTFS file system has an ACL no matter what. 

Not completely true. It can have a NULL ACL which grants permission to everyone.

 

You're right, my mistake on that point.

 

I'm not convinced ACEs should be separate resources, because they don't exist outside of an ACL.

Files don't exist outside their parent directories, but Puppet does not use a single resource to model the entire filesystem.  File_lines don't exist outside their File, but stdlib provides it anyway.  File fragments don't exist outside the file assembled from them, but the Concat module provides them anyway.  Experience proves that separately modeling pieces of a larger physical resource can be a powerful and effective approach.

 

For example, consider properties that extend Puppet::Property::List, like the `groups` property for the `user` resource. You specify either the complete or minimum list of groups the user should belong to, as opposed to specifying each user's group and whether the user should be present/absent from the group.

Ok, I'll retract my claim that you "need" to model ACEs as their own resources, which was a bit of an overstatement.  I acknowledge that it is possible to create an Acl resource type that models an ACL and a subset of its ACEs, all in one resource.  I don't think the model Bob first floated does an adequate, usable, job of that, but potential improvements have already come out of this discussion.

Nevertheless, I maintain that an all-in-one model is an inferior choice for the target space, in part because it centralizes the model to an unneeded and unwanted degree, and in part because it requires complex parameter values which will present a practical usage barrier for folks to overcome.

> Yes, the order of ACEs needs to be specified, and is one reason why permissions cannot be modeled solely using ACEs.

No.  I acknowledge that there is a role for a resource type modeling an overall ACL, but not because of the need to manage ACE order within.  Again, look at the Concat module, which does not rely on the umbrella Concat resource type to manage the order of fragments.


John

[Rob Reynolds]

Apologies, I should have been more explicit that the line count was not lines of code but lines total with formatting in the way that I would format it, which includes spaces between resources. 

Which is to say, an arbitrary metric was used in talking about an example that gives a general idea of what was meant by resource explosion. I didn't realize there would be scrutiny on the  mechanism I used to count the lines, otherwise I would have paid more attention there or picked a better metric, as you have suggested.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/67e7a0c6-29f5-4227-a49f-d3aee19f508f%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[John Bollinger]

On Tuesday, October 29, 2013 4:06:45 PM UTC-5, John Bollinger wrote:

No.  I acknowledge that there is a role for a resource type modeling an overall ACL, but not because of the need to manage ACE order within.  Again, look at the Concat module, which does not rely on the umbrella Concat resource type to manage the order of fragments.

Sorry, I think that's unclear.  I meant that fragment order is not specified via Concat resources, though indeed the Concat type is involved in assembling fragments in the right order.  Nevertheless, I maintain that if ACE ordering could be managed entirely via an Ace type if there were no other use for a central Acl type.


John

[John Bollinger]

On Tuesday, October 29, 2013 4:11:08 PM UTC-5, Rob Reynolds wrote:

Apologies, I should have been more explicit that the line count was not lines of code but lines total with formatting in the way that I would format it, which includes spaces between resources. 

Which is to say, an arbitrary metric was used in talking about an example that gives a general idea of what was meant by resource explosion. I didn't realize there would be scrutiny on the  mechanism I used to count the lines, otherwise I would have paid more attention there or picked a better metric, as you have suggested.

I'm not scrutinizing your mechanism, I'm scrutinizing your argument.  Since we agree that line count is not a good metric, I hope we can focus on my real point that using separate resources to model ACEs does not significantly increase the overall complexity of the manifest set vs. alternative representations with similar expressiveness.

John

[Rob Reynolds]

On Tue, Oct 29, 2013 at 3:29 PM, John Bollinger <john.bo...@stjude.org> wrote:

On Monday, October 28, 2013 4:05:47 PM UTC-5, Rob Reynolds wrote:

So, an array then.  But an array of what, exactly?  Your hash values are already arrays themselves -- whose meanings are largely opaque to me, by the way -- so will you now have an array of arrays?  An array of hashes would be more self-documentary, but wait: those inner hashes now bear a strong resemblance to resource declarations.  Why was it, again, that you didn't want a separate resource type for ACEs?

Mostly because of resource explosion. https://gist.github.com/ferventcoder/7204591 - Note that it is 20 lines to say the same thing in 8 lines.  But is it the right answer? I think there is a happy medium here we should explore where one or both options could live.

 

You achieve 8 lines vs. 20 by choosing a form that favors concision over clarity (and by your choice of where to break lines).  To represent ACEs as arrays as the example code does, the Acl type must make assumptions about the order of elements, and it must also either make inferences about the meaning of other elements based on their values (which is risky), or else limit which combinations of ACE properties can be modeled (which is unsatisfying).  As for self-documentation, where you started this discussion, the array representation of ACEs severely lacking.

A form more like this would be better in all those regards:

acl { 'c:/windows/temp/some_dir':
  inherit => true,
  purge => false,
  permissions => [
    { identity => 'bob', rights => 'modify', type => 'allow', inherit => 'all', propagate => 'all' },
    { identity => 'tim', rights => 'read_execute' }
  ],
}

At least the ACEs are then reasonably easy to interpret (by both humans and machines), but it's not much less verbose than a form with separate ACEs:

acl { 'c:/windows/temp/some_dir':
  inherit => true,
  purge => false,
}


ace {
  'bob/some_dir': identity => 'bob', file => 'c:/windows/temp/some_dir', priority => 1, rights => 'modify', type => 'allow', inherit => 'all', propagate => 'all';

  'tim/some_dir': identity => 'tim', file => 'c:/windows/temp/some_dir', priority => 100, rights => 'read_execute';
}

So type would be file in this case. How would you grow it to the other types besides files and folders? ie. services, registry, etc

 

That's 8 non-empty lines as I wrote it, btw, if you really want to use such a metric (a token count would be less style-dependent).  Plus all the parameter values have simple types, which I think is a big usage win.

You mentioned concern about a "resource explosion", but I don't think the example actually went there.  Keep in mind that a major objective of the modern form of ACL inheritance was to minimize the number of distinct ACE objects in the system, keeping them toward the root of the tree, with the happy result that the main cases for Puppet to address involve relatively few ACLs and ACEs that actually need to be managed.


John

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/67e7a0c6-29f5-4227-a49f-d3aee19f508f%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Rob Reynolds]

On Tue, Oct 29, 2013 at 3:29 PM, John Bollinger <john.bo...@stjude.org> wrote:

On Monday, October 28, 2013 4:05:47 PM UTC-5, Rob Reynolds wrote:

So, an array then.  But an array of what, exactly?  Your hash values are already arrays themselves -- whose meanings are largely opaque to me, by the way -- so will you now have an array of arrays?  An array of hashes would be more self-documentary, but wait: those inner hashes now bear a strong resemblance to resource declarations.  Why was it, again, that you didn't want a separate resource type for ACEs?

Mostly because of resource explosion. https://gist.github.com/ferventcoder/7204591 - Note that it is 20 lines to say the same thing in 8 lines.  But is it the right answer? I think there is a happy medium here we should explore where one or both options could live.

 

You achieve 8 lines vs. 20 by choosing a form that favors concision over clarity (and by your choice of where to break lines).  To represent ACEs as arrays as the example code does, the Acl type must make assumptions about the order of elements, and it must also either make inferences about the meaning of other elements based on their values (which is risky), or else limit which combinations of ACE properties can be modeled (which is unsatisfying).  As for self-documentation, where you started this discussion, the array representation of ACEs severely lacking.

A form more like this would be better in all those regards:

acl { 'c:/windows/temp/some_dir':
  inherit => true,
  purge => false,
  permissions => [
    { identity => 'bob', rights => 'modify', type => 'allow', inherit => 'all', propagate => 'all' },
    { identity => 'tim', rights => 'read_execute' }
  ],
}

I definitely like this. I had originally started down this path and thought it was too verbose, but seeing it again and after discussing this, I think I like the direction and clarity this provides. It allows ordering among other things.

 

At least the ACEs are then reasonably easy to interpret (by both humans and machines), but it's not much less verbose than a form with separate ACEs:

acl { 'c:/windows/temp/some_dir':
  inherit => true,
  purge => false,
}

ace {
  'bob/some_dir': identity => 'bob', file => 'c:/windows/temp/some_dir', priority => 1, rights => 'modify', type => 'allow', inherit => 'all', propagate => 'all';

  'tim/some_dir': identity => 'tim', file => 'c:/windows/temp/some_dir', priority => 100, rights => 'read_execute';
}

That's 8 non-empty lines as I wrote it, btw, if you really want to use such a metric (a token count would be less style-dependent).  Plus all the parameter values have simple types, which I think is a big usage win.

You mentioned concern about a "resource explosion", but I don't think the example actually went there.  Keep in mind that a major objective of the modern form of ACL inheritance was to minimize the number of distinct ACE objects in the system, keeping them toward the root of the tree, with the happy result that the main cases for Puppet to address involve relatively few ACLs and ACEs that actually need to be managed.


John

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/67e7a0c6-29f5-4227-a49f-d3aee19f508f%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[John Bollinger]

 
The application module in question would simply declare the needed Ace resource(s).  We're talking about permissions for a user belonging to the module, so there should be no conflict with any other module.  Such an ACE resource might look like my previous example:

ace { 'my_app_user/some_dir':
  identity => 'my_app_user',
  file => 'c:/windows/temp/some_dir',
  priority => 100,

  rights => 'modify',
  type => 'allow'
}

John

[John Bollinger]

On Tuesday, October 29, 2013 4:34:48 PM UTC-5, Rob Reynolds wrote:

On Tue, Oct 29, 2013 at 3:29 PM, John Bollinger <john.bo...@stjude.org> wrote:

ace {

  'bob/some_dir': identity => 'bob', file => 'c:/windows/temp/some_dir', priority => 1, rights => 'modify', type => 'allow', inherit => 'all', propagate => 'all';

  'tim/some_dir': identity => 'tim', file => 'c:/windows/temp/some_dir', priority => 100, rights => 'read_execute';
}

So type would be file in this case. How would you grow it to the other types besides files and folders? ie. services, registry, etc

The first approach that occurs to me is to give the Ace type a separate parameter to identify each type of object to which it might apply.  These could be, but do not need to be, mutually exclusive.  Service example:

ace { 'my_app_user/My Application Service':
  identity => 'my_app_user',
  service => 'My Application Service',
  # ...
}

And that brings another another wrinkle to mind: suppose you want to equivalent ACEs to multiple objects that are not related by common a common ancestor, or where you don't want to modify an ancestor ACL.  You could conceivably model it concisely by allowing Ace resources to specify arrays of file names, service names, registry IDs, etc. to which they apply.  Although you could conceivably make that possible for whole ACLs, too, individual ACEs are more likely to be shareable than are whole ACLs.


John

[Rob Reynolds]

Agreed here. What we were just talking about was say dropping anything about the ACE knowing what it is applied to, that would go onto the ACL.

 

John

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/a808b3cf-d51d-4a2c-b9b5-eaa20016dba3%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Josh Cooper]

On Tue, Oct 29, 2013 at 2:57 PM, Rob Reynolds <r...@puppetlabs.com> wrote:

On Tue, Oct 29, 2013 at 4:53 PM, John Bollinger <john.bo...@stjude.org> wrote:

On Tuesday, October 29, 2013 4:34:48 PM UTC-5, Rob Reynolds wrote:

On Tue, Oct 29, 2013 at 3:29 PM, John Bollinger <john.bo...@stjude.org> wrote:

ace {

  'bob/some_dir': identity => 'bob', file => 'c:/windows/temp/some_dir', priority => 1, rights => 'modify', type => 'allow', inherit => 'all', propagate => 'all';



  'tim/some_dir': identity => 'tim', file => 'c:/windows/temp/some_dir', priority => 100, rights => 'read_execute';


}

So type would be file in this case. How would you grow it to the other types besides files and folders? ie. services, registry, etc

The first approach that occurs to me is to give the Ace type a separate parameter to identify each type of object to which it might apply.  These could be, but do not need to be, mutually exclusive.  Service example:

ace { 'my_app_user/My Application Service':
  identity => 'my_app_user',
  service => 'My Application Service',
  # ...
}

And that brings another another wrinkle to mind: suppose you want to equivalent ACEs to multiple objects that are not related by common a common ancestor, or where you don't want to modify an ancestor ACL.  You could conceivably model it concisely by allowing Ace resources to specify arrays of file names, service names, registry IDs, etc. to which they apply.  Although you could conceivably make that possible for whole ACLs, too, individual ACEs are more likely to be shareable than are whole ACLs.

Agreed here. What we were just talking about was say dropping anything about the ACE knowing what it is applied to, that would go onto the ACL.

So something like:

ace { 'admins':

  identity => 'Administrators',

  rights   => [full],

}

ace { 'users':

  identity => 'Users',

  rights   => [read_execute, list]

}

acl { 'c:\somedir':

  ensure => present,

  permissions => [

    Ace['admins'],

    Ace['users']

  ]

}

acl { 'c:\somesensitivedir':

  ensure => present,

  purge => true,

  protected => true,

  permissions => [

    Ace['admins']

  ],

}

So `c:\somedir` describes the complete set of explicit ACEs, though it may inherit ACEs from its parent.

On the other hand, `c:\somesensitivedir` is protected (breaks inheritance), it only allows admins full control, and purges any other ACE.

Thoughts?

Josh

[Rob Reynolds]

We also talked about both the ability to use both defined and inlined ace resources within an acl (a best of both world's approach):

ace { 'admins':

  identity => 'Administrators',

  rights   => [full],

}

acl { 'c:\somedir':

  ensure => present,

  permissions => [

    Ace['admins'],

    {identity => 'tim', rights=> 'read'}

  ]

}

That way you can define reusable aces and then inline the ones that you may not share. 

This allows you to build composable aces that can apply to multiple acls and types (files/services/etc), but also to be concise if that is your preference. 

Thoughts?

acl { 'c:\somesensitivedir':

  ensure => present,

  purge => true,

  protected => true,

  permissions => [

    Ace['admins']

  ],

}

So `c:\somedir` describes the complete set of explicit ACEs, though it may inherit ACEs from its parent.

On the other hand, `c:\somesensitivedir` is protected (breaks inheritance), it only allows admins full control, and purges any other ACE.

Thoughts?

Josh

--

Josh Cooper

Developer, Puppet Labs

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CA%2Bu97um6zAa_wiBkL7dh4yNBqbhdrUUVNgNCAs%3DEjgC89aHq1Q%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

[John Bollinger]

On Tuesday, October 29, 2013 6:06:52 PM UTC-5, Josh Cooper wrote:

On Tue, Oct 29, 2013 at 2:57 PM, Rob Reynolds <r...@puppetlabs.com> wrote:

[...]

 What we were just talking about was say dropping anything about the ACE knowing what it is applied to, that would go onto the ACL.

So something like:

ace { 'admins':

  identity => 'Administrators',

  rights   => [full],

}

ace { 'users':

  identity => 'Users',

  rights   => [read_execute, list]

}

acl { 'c:\somedir':

  ensure => present,

  permissions => [

    Ace['admins'],

    Ace['users']

  ]

}

acl { 'c:\somesensitivedir':

  ensure => present,

  purge => true,

  protected => true,

  permissions => [

    Ace['admins']

  ],

}

So `c:\somedir` describes the complete set of explicit ACEs, though it may inherit ACEs from its parent.

On the other hand, `c:\somesensitivedir` is protected (breaks inheritance), it only allows admins full control, and purges any other ACE.

Thoughts?

It would probably work, but I don't like it because it takes ACEs from being bona fide resources to being plain data objects merely masquerading as resources.  Halloween isn't until tomorrow.  Seriously, though, shoehorning an object into a context where it doesn't quite fit tends to lead to trouble; just look at the myriad historical and continuing issues around the edges of resource-like class declarations for a close-to-home example.  On the more practical side, I would like to be able to declare an ACE and rely on it being applied, without regard to whether the general properties of the overall ACL(s) to which it is applied are also managed.

I really think it makes sense to keep the (DSL view of the) data structure simple.  That makes the resource types easier to understand and easier to integrate with external data sources, including via automated parameter binding.  From that perspective I prefer to avoid relying on complex parameter value types, and I particularly dislike relying on resource references to hook things together, as references cannot currently be expressed in external data.  Additionally, relying on resource references brings in all the issues around ensuring resources are declared exactly once.  That can easily be avoided here, so why would you intentionally choose to not avoid it?


John

[Rob Reynolds]

Josh and I researched some more, then discussed some possibilities at length with someone from the modules team. It shaped how we were thinking about defining the types quite a bit.

Interesting things to note: 

• Modeling towards the real world, neither an ACE nor an ACL is ensurable. The only type that is ensurable is a Security Descriptor (which I was formerly collapsing into the ACL construct to reduce the number of types), as Security Descriptor is the only artifact that can exist on its own on a Windows system.
• Defining an ACE only approach, while very simple, has several problems including:
  
• An identity can hold multiple ACEs on a singular resource. [ACL]
• It doesn't leave a place to define the owner of the resource. [Security Descriptor]
• It doesn't really guarantee an order (rather a priority was proposed that might help build an order). [ACL]
• It doesn't allow the ACE to be composed into multiple resources (i.e. reusability) since it is coupled to the resource.
• It doesn't allow for specifying whether permissions are inherited from parent resources. [Security Descriptor]
• It didn't help us define whether to purge non-managed resources.
• We're leaning towards some number of types and defined types (similar to apache and mysql modules) so you can model to the level of detail desired.

These things will be updated in the ARM proposal. So far this discussion has brought out some great points. Once the ARM has been accepted I will link to it so we can continue tearing it apart. :)  Expect that to be in the next day or so.

More Detail

"An identity can be in multiple ACEs on a singular resource" :

Let's take a look at a set of ACEs (that are part of the DACL in a security descriptor) on an actual directory -

C:\>icacls "C:\windows"
C:\windows NT SERVICE\TrustedInstaller:(F)
           NT SERVICE\TrustedInstaller:(CI)(IO)(F)
           NT AUTHORITY\SYSTEM:(M)
           NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
           BUILTIN\Administrators:(M)
           BUILTIN\Administrators:(OI)(CI)(IO)(F)
           BUILTIN\Users:(RX)
           BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
           CREATOR OWNER:(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

Note BUILTIN\Administrators:(M) & BUILTIN\Administrators:(OI)(CI)(IO)(F) specifies that Administrators has two different explicit ACEs on C:\Windows. If they were inherited, you would see an (I). The first specifies that Administrators have Modify access to the directory. The second specifies that Administrators have Full access to all files and folders inside that directory, but not the directory itself.

 

John

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/7024cede-9c4b-4e0b-8be5-4d7b12c56beb%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Dustin J. Mitchell]

This is an exciting and deep conversation, and very relevant to
Mozilla's interests, as we've been struggling with the narrow pinhole
of permissions that is mode.

The general concept that I would like to emphasize is that the puppet
language has facilities for abstraction, and that can make
conversations about conciseness of expression moot. If the
fundamental type implementations are very granular (e.g., security
descriptors and ACEs), the module itself can provide higher-level
abstractions over those types for common uses, while allowing users to
use the types directly for the more unusual cases.

As regards the ability to specify ACEs for a particular path in
different places: this reminds me of issues with group membership in
POSIX, where it's difficult to add two different users, defined in
different modules, to the same group. That's an unfortunate
limitation that's difficult to work around with puppet abstractions,
and it'd be great if this module didn't have similar issues.

Dustin

[Rob Reynolds]

Here is the ARM - https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md

Also have some questions listed at https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md#open-questions

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAJtE5vQJvPnuCOts%2BMRm%3DzJkSiJ7X%2BO-TrvBOboq1X25H1qaRA%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

[John Bollinger]

On Wednesday, November 6, 2013 5:50:35 AM UTC-6, Rob Reynolds wrote:

Here is the ARM - https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md

Also have some questions listed at https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md#open-questions

And now for the "continue tearing it apart" part :-).  Issues that occur to me upon first reading of the ARM, in no particular order:

1. I continue to maintain that it is inappropriate to use resource types to model plain data.  A resource type should model something that can be applied in isolation to the target system.  The proposed Ace type does not satisfy that criterion.  If there is a perceived need for the DSL to support new or custom data types then that should be addressed as such, not by trying to make custom resource types serve that role.  Absent custom data types, the types we have must serve.

2. The data types expected of all resource properties and parameters should be limited to those that can be provided by hiera.  Resource references are not among those, as far as I am aware.  If this principle is not followed, and especially if it is not followed for essential parameters such as security_descriptor.dacl and acl.permissions, then it will not be possible to externalize the data for these resources.

3. If security descriptors and/or ACLs may in the future support other types of objects than files, then there is a potential for name (title) collisions.  Unlike many resource types, the ones documented in ARM-16 do not appear to have any property separate from their titles by which to specify the object to which they apply (compare Exec.command or File.path).  Moreover, even that might be enough.  Puppet has no support for compound resource identifiers -- which causes problems for Packages on multilib systems, for example -- so although (type, identifier) may distinguish (say) a specific security descriptor to a human, Puppet doesn't know what to do with that.  Instead, how about using URIs:

security_descriptor {
  'file:/absolute/path':
    # ...
    ;
  'other_protocol:/looks/like/a/path'':
    # ...
    ;
}

4. It is inadequate and mildly inappropriate for the 'ensure' parameter of the Acl resource type to direct whether its ACEs are present or absent, as opposed to whether the ACL itself is present or absent.  We already covered that a Windows object may be without any DACL at all, with that being a distinct state from having an empty DACL.  It is unclear to me how under ARM-16 to model the case in which an object has no DACL.  Moreover, it may easily be the case that one wants to enforce at the same time that some ACEs are present an a given ACL whereas others are absent from that ACL; I don't see how that can be modeled under ARM-16.

5. Inasmuch as multiple ACEs in the same ACL may be associated with the same identity, I think ARM-16 does not present adequate means to identify which ACEs to operate upon.  I know I suggested earlier in the discussion that ACEs be modeled as their own resources (though ARM-16 doesn't fully do this), but every resource must have a unique, recognizable identity.  Otherwise, it is impossible to know how to sync the resource.  I now think that the abstraction needs to be a bit higher level: all the security assertions pertaining to a given principal ("identity") for a given object.  It would also be possible to split that up into granted and denied permission sets, or else into specific permission types (r, w, x, etc.), but I don't see how to avoid grouping by principal.

6. ARM-16 does not address the issue of ordering the permissions specified for a given object relative to unmanaged permissions present on that object (when purging is disabled).  Also, I suppose the intent is that the managed permissions appear in the target ACL in the same relative order that they appear in the Acl resource's 'permissions' array, but the ARM does not actually specify that.

7. ARM-16 does not provide a viable mechanism for access control management to be decentralized across a manifest set.  It requires ALL the permissions that are to be managed for a given object to be known to a single class.  As the ARM currently stands, that issue cannot even be mitigated by relying on externalizing the permissions data (see (2)).


John

[John Bollinger]

On Thursday, November 7, 2013 10:47:56 AM UTC-6, John Bollinger wrote:

On Wednesday, November 6, 2013 5:50:35 AM UTC-6, Rob Reynolds wrote:

Here is the ARM - https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md

Also have some questions listed at https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md#open-questions

And now for the "continue tearing it apart" part :-).  Issues that occur to me upon first reading of the ARM, in no particular order:

8.  The ARM appears to indicate that Acl resources are expected to identify the object to which they apply via their titles.  That is well, but it leaves me wondering why it is then necessary or appropriate for the Security_descriptor type to redundantly identify a DACL via property 'dacl'.

9. With respect to the note in the ARM about errors related to narrowing permissions, it would be highly desirable for the module to allow users to specify minimum permission requirements without having to declare exact permissions.  That is, if I want to declare that some user can read a certain file, but I don't care whether he can modify it, then I don't want to be stuck guessing at or managing that file's inherited permissions in order to specify an acceptable exact set of permissions for that user.


John
 

[Rob Reynolds]

On Thu, Nov 7, 2013 at 1:35 PM, John Bollinger <john.bo...@stjude.org> wrote:

On Thursday, November 7, 2013 10:47:56 AM UTC-6, John Bollinger wrote:

On Wednesday, November 6, 2013 5:50:35 AM UTC-6, Rob Reynolds wrote:

Here is the ARM - https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md

Also have some questions listed at https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md#open-questions

And now for the "continue tearing it apart" part :-).  Issues that occur to me upon first reading of the ARM, in no particular order:

8.  The ARM appears to indicate that Acl resources are expected to identify the object to which they apply via their titles.  That is well, but it leaves me wondering why it is then necessary or appropriate for the Security_descriptor type to redundantly identify a DACL via property 'dacl'.

Actually that is not the case. It is just a unique title so an ACL could be applied to multiple security descriptor types. Note that nowhere is a path defined here: https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md#acl-type

 

9. With respect to the note in the ARM about errors related to narrowing permissions, it would be highly desirable for the module to allow users to specify minimum permission requirements without having to declare exact permissions.  That is, if I want to declare that some user can read a certain file, but I don't care whether he can modify it, then I don't want to be stuck guessing at or managing that file's inherited permissions in order to specify an acceptable exact set of permissions for that user.

John
 

--

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/18e68401-3f16-4551-850a-18a3c68eb8ed%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Brian Stark]

On Thursday, November 7, 2013 9:47:56 AM UTC-7, John Bollinger wrote:

On Wednesday, November 6, 2013 5:50:35 AM UTC-6, Rob Reynolds wrote:

Here is the ARM - https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md

Also have some questions listed at https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md#open-questions

And now for the "continue tearing it apart" part :-).  Issues that occur to me upon first reading of the ARM, in no particular order:

3. If security descriptors and/or ACLs may in the future support other types of objects than files, then there is a potential for name (title) collisions.  Unlike many resource types, the ones documented in ARM-16 do not appear to have any property separate from their titles by which to specify the object to which they apply (compare Exec.command or File.path).  Moreover, even that might be enough.  Puppet has no support for compound resource identifiers -- which causes problems for Packages on multilib systems, for example -- so although (type, identifier) may distinguish (say) a specific security descriptor to a human, Puppet doesn't know what to do with that.  Instead, how about using URIs:

security_descriptor {
  'file:/absolute/path':
    # ...
    ;
  'other_protocol:/looks/like/a/path'':
    # ...
    ;
}

John

This is incredibly important to me.  I often have to manage domain user's access to private keys stored in the certificate stores (i.e. cert:\\LocalMachine\My\{thumbprint}) - in fact, this is my primary need for any ACLs for Windows.  As noted in the ARM, registry key access would be nice, although I have not needed it.

My need is to set multiple permissions on the same certificate from multiple modules, which to this point is a terrible mess.  I don't see anything documented that would allow this scenario to work - adding to an ACL defined defined in module A from module B.  Since my primary use case for ACLs is private key permissions, I will just through this out to noodle on:  Module A:Cert defines a certificate and installs it to LocalMachine\My and creates an ACL with no ACEs.  A, with some knowledge of the user needing private key access to the cert in A:Cert adds to the ACL defined there.  Module B requires the same certificate and PK access defined in A:Cert, so it includes A:Cert, but would also need to add to A:Cert's defined ACL.

The problem above has been my only issue that I have encountered in Puppet that I have yet to come up with a graceful solution to.  From reading the ARM, I don't think this will solve it, but just wanted to through out a use case that could be extended to file ACLs as well.

Brian

[John Bollinger]

On Thursday, November 7, 2013 1:48:24 PM UTC-6, Rob Reynolds wrote:

On Thu, Nov 7, 2013 at 1:35 PM, John Bollinger <john.bo...@stjude.org> wrote:

8.  The ARM appears to indicate that Acl resources are expected to identify the object to which they apply via their titles.  That is well, but it leaves me wondering why it is then necessary or appropriate for the Security_descriptor type to redundantly identify a DACL via property 'dacl'.

Actually that is not the case. It is just a unique title so an ACL could be applied to multiple security descriptor types. Note that nowhere is a path defined here: https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md#acl-type

Ok.  In that case, the Acl resource type as currently documented in ARM-16 is subject to my criticism (1).  That is, it is not a true resource type, but rather plain data dressed up in resource clothes.  A sheep in wolf's clothing, as it were.


John

[Rob Reynolds]

On Thu, Nov 7, 2013 at 5:26 PM, Brian Stark <bds...@gmail.com> wrote:

On Thursday, November 7, 2013 9:47:56 AM UTC-7, John Bollinger wrote:

On Wednesday, November 6, 2013 5:50:35 AM UTC-6, Rob Reynolds wrote:

Here is the ARM - https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md

Also have some questions listed at https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md#open-questions

And now for the "continue tearing it apart" part :-).  Issues that occur to me upon first reading of the ARM, in no particular order:

3. If security descriptors and/or ACLs may in the future support other types of objects than files, then there is a potential for name (title) collisions.  Unlike many resource types, the ones documented in ARM-16 do not appear to have any property separate from their titles by which to specify the object to which they apply (compare Exec.command or File.path).  Moreover, even that might be enough.  Puppet has no support for compound resource identifiers -- which causes problems for Packages on multilib systems, for example -- so although (type, identifier) may distinguish (say) a specific security descriptor to a human, Puppet doesn't know what to do with that.  Instead, how about using URIs:

security_descriptor {
  'file:/absolute/path':
    # ...
    ;
  'other_protocol:/looks/like/a/path'':
    # ...
    ;
}

John

This is incredibly important to me.  I often have to manage domain user's access to private keys stored in the certificate stores (i.e. cert:\\LocalMachine\My\{thumbprint}) - in fact, this is my primary need for any ACLs for Windows.  As noted in the ARM, registry key access would be nice, although I have not needed it.

My need is to set multiple permissions on the same certificate from multiple modules, which to this point is a terrible mess.  I don't see anything documented that would allow this scenario to work - adding to an ACL defined defined in module A from module B.  Since my primary use case for ACLs is private key permissions, I will just through this out to noodle on:  Module A:Cert defines a certificate and installs it to LocalMachine\My and creates an ACL with no ACEs.  A, with some knowledge of the user needing private key access to the cert in A:Cert adds to the ACL defined there.  Module B requires the same certificate and PK access defined in A:Cert, so it includes A:Cert, but would also need to add to A:Cert's defined ACL.

With this case I think if we separate title from target, would it meet the needs? It would allow you to hit the same resource from several areas without a conflicting resource/name issue.

 

The problem above has been my only issue that I have encountered in Puppet that I have yet to come up with a graceful solution to.  From reading the ARM, I don't think this will solve it, but just wanted to through out a use case that could be extended to file ACLs as well.

Brian

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/9eb5c708-cb80-4f0d-932d-d9227f75c47e%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Rob Reynolds]

On Thu, Nov 7, 2013 at 10:47 AM, John Bollinger <john.bo...@stjude.org> wrote:

On Wednesday, November 6, 2013 5:50:35 AM UTC-6, Rob Reynolds wrote:

Here is the ARM - https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md

Also have some questions listed at https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md#open-questions

And now for the "continue tearing it apart" part :-).  Issues that occur to me upon first reading of the ARM, in no particular order:

1. I continue to maintain that it is inappropriate to use resource types to model plain data.  A resource type should model something that can be applied in isolation to the target system.  The proposed Ace type does not satisfy that criterion.  If there is a perceived need for the DSL to support new or custom data types then that should be addressed as such, not by trying to make custom resource types serve that role.  Absent custom data types, the types we have must serve.

I'm not sure we want to set some precedent of a data type that we don't have. So agreed.

 

2. The data types expected of all resource properties and parameters should be limited to those that can be provided by hiera.  Resource references are not among those, as far as I am aware.  If this principle is not followed, and especially if it is not followed for essential parameters such as security_descriptor.dacl and acl.permissions, then it will not be possible to externalize the data for these resources.

This is the one that hit me as the biggest need we need to make sure we can serve and I spent some considerable time thinking and spiking out some concepts.  I found what appears to work with hiera. Will show proposal in next email.

 

3. If security descriptors and/or ACLs may in the future support other types of objects than files, then there is a potential for name (title) collisions.  Unlike many resource types, the ones documented in ARM-16 do not appear to have any property separate from their titles by which to specify the object to which they apply (compare Exec.command or File.path).  Moreover, even that might be enough.  Puppet has no support for compound resource identifiers -- which causes problems for Packages on multilib systems, for example -- so although (type, identifier) may distinguish (say) a specific security descriptor to a human, Puppet doesn't know what to do with that.  Instead, how about using URIs:

security_descriptor {
  'file:/absolute/path':
    # ...
    ;
  'other_protocol:/looks/like/a/path'':
    # ...
    ;
}

4. It is inadequate and mildly inappropriate for the 'ensure' parameter of the Acl resource type to direct whether its ACEs are present or absent, as opposed to whether the ACL itself is present or absent.  We already covered that a Windows object may be without any DACL at all, with that being a distinct state from having an empty DACL.  It is unclear to me how under ARM-16 to model the case in which an object has no DACL.  Moreover, it may easily be the case that one wants to enforce at the same time that some ACEs are present an a given ACL whereas others are absent from that ACL; I don't see how that can be modeled under ARM-16.

I tend to agree with this in retrospect. With ensure, we should be ensuring that on a particular security descriptor that is has a DACL with a particular set of ACEs. Breaking it out into three different types makes that process too complex. It would be better to start with a simple acl that allows us to treat it as a proper resource.

 

5. Inasmuch as multiple ACEs in the same ACL may be associated with the same identity, I think ARM-16 does not present adequate means to identify which ACEs to operate upon.  I know I suggested earlier in the discussion that ACEs be modeled as their own resources (though ARM-16 doesn't fully do this), but every resource must have a unique, recognizable identity.  Otherwise, it is impossible to know how to sync the resource.  I now think that the abstraction needs to be a bit higher level: all the security assertions pertaining to a given principal ("identity") for a given object.  It would also be possible to split that up into granted and denied permission sets, or else into specific permission types (r, w, x, etc.), but I don't see how to avoid grouping by principal.

6. ARM-16 does not address the issue of ordering the permissions specified for a given object relative to unmanaged permissions present on that object (when purging is disabled).  Also, I suppose the intent is that the managed permissions appear in the target ACL in the same relative order that they appear in the Acl resource's 'permissions' array, but the ARM does not actually specify that.

I thought we covered that, but from reading through I guess we didn't specify. I will make that update in the updated armature request. 

 

7. ARM-16 does not provide a viable mechanism for access control management to be decentralized across a manifest set.  It requires ALL the permissions that are to be managed for a given object to be known to a single class.  As the ARM currently stands, that issue cannot even be mitigated by relying on externalizing the permissions data (see (2)).

You are correct. Would ensuring hiera works and decoupling the title from the target would alleviate most/all of this concern?

 

John

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/ef2aeed9-115e-457f-b567-a96d2140e026%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Rob Reynolds]

Consider the following set:

acl {'c:/temp':

  ensure => present,

  permissions => [

    {identity => 'Administrators', rights => [full]}

  ],

  owner => 'Administrators',

  inherit_parent_permissions => true

}

acl { 'temp_dir_module_name':

  target => 'c:/temp',

  ensure => present,

  permissions => [

    {identity => 'bob', rights => [read,execute]},

    {identity => 'tim', rights => [read,execute]}

  ],

}

acl { 'temp_dir_module2_name':

  target => 'c:/temp',

  ensure => present,

  permissions => [

    {identity => 'bill', rights => [full], affects => self_only},

    {identity => 'tim', rights => [read,execute]}

  ],

}

[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.

[Rob Reynolds]

Dustin,

 I've filed https://tickets.puppetlabs.com/browse/MODULES-962 for working with POSIX.

On Thu, Oct 31, 2013 at 6:06 PM, Dustin J. Mitchell <dus...@v.igoro.us> wrote:

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAJtE5vQJvPnuCOts%2BMRm%3DzJkSiJ7X%2BO-TrvBOboq1X25H1qaRA%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

Rob Reynolds

Developer, Puppet Labs

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

[Rob Reynolds]

On Thu, Nov 7, 2013 at 5:26 PM, Brian Stark <bds...@gmail.com> wrote:

On Thursday, November 7, 2013 9:47:56 AM UTC-7, John Bollinger wrote:

On Wednesday, November 6, 2013 5:50:35 AM UTC-6, Rob Reynolds wrote:

Here is the ARM - https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md

Also have some questions listed at https://github.com/puppetlabs/armatures/blob/master/arm-16.acls/index.md#open-questions

And now for the "continue tearing it apart" part :-).  Issues that occur to me upon first reading of the ARM, in no particular order:

3. If security descriptors and/or ACLs may in the future support other types of objects than files, then there is a potential for name (title) collisions.  Unlike many resource types, the ones documented in ARM-16 do not appear to have any property separate from their titles by which to specify the object to which they apply (compare Exec.command or File.path).  Moreover, even that might be enough.  Puppet has no support for compound resource identifiers -- which causes problems for Packages on multilib systems, for example -- so although (type, identifier) may distinguish (say) a specific security descriptor to a human, Puppet doesn't know what to do with that.  Instead, how about using URIs:

security_descriptor {
  'file:/absolute/path':
    # ...
    ;
  'other_protocol:/looks/like/a/path'':
    # ...
    ;
}

John

This is incredibly important to me.  I often have to manage domain user's access to private keys stored in the certificate stores (i.e. cert:\\LocalMachine\My\{thumbprint}) - in fact, this is my primary need for any ACLs for Windows.  As noted in the ARM, registry key access would be nice, although I have not needed it.

I've added this for registry - https://tickets.puppetlabs.com/browse/MODULES-959

If you feel that one would be necessary for certificate permissions, I think that would be a good use case for an additional ticket on the MODULES project in JIRA.

 

My need is to set multiple permissions on the same certificate from multiple modules, which to this point is a terrible mess.  I don't see anything documented that would allow this scenario to work - adding to an ACL defined defined in module A from module B.  Since my primary use case for ACLs is private key permissions, I will just through this out to noodle on:  Module A:Cert defines a certificate and installs it to LocalMachine\My and creates an ACL with no ACEs.  A, with some knowledge of the user needing private key access to the cert in A:Cert adds to the ACL defined there.  Module B requires the same certificate and PK access defined in A:Cert, so it includes A:Cert, but would also need to add to A:Cert's defined ACL.

The problem above has been my only issue that I have encountered in Puppet that I have yet to come up with a graceful solution to.  From reading the ARM, I don't think this will solve it, but just wanted to through out a use case that could be extended to file ACLs as well.

This is allowed with acls, with a note that this should be used with care because it could cause thrashing in reports - https://github.com/puppetlabs/puppetlabs-acl#same-target-multiple-resources

 

Brian

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/9eb5c708-cb80-4f0d-932d-d9227f75c47e%40googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

Rob Reynolds

Developer, Puppet Labs

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