On Monday, October 28, 2013 11:54:25 AM UTC-5, Rob Reynolds wrote:
>
>
>
>
> On Mon, Oct 28, 2013 at 8:42 AM, jcbollinger
> <[email protected]<javascript:>
> > 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
--
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.
