[...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 [email protected].
> 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
Developer, Puppet Labs
Join us at PuppetConf 2014, September 23-24 in San Francisco
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAMJiBK5QMhPn%2BMKAYNk3%3DqBEdeU%2BEn2VLJvp7_50vZWJBGwEEw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
