On Mon, Oct 28, 2013 at 12:59 PM, John Bollinger
<john.bollin...@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
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CA%2Bu97um01MQHq8r0TYdWLxyUFZA2tL5nYw7TLC0bSzjC-4nfGg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
