On Tuesday, October 29, 2013, Josh Cooper wrote:
>
>
>
> On Tue, Oct 29, 2013 at 2:57 PM, Rob Reynolds
> <[email protected]<javascript:_e({}, 'cvml', '[email protected]');>
> > wrote:
>
>>
>>
>>
>> On Tue, Oct 29, 2013 at 4:53 PM, John Bollinger <
>> [email protected] <javascript:_e({}, 'cvml',
>> '[email protected]');>> 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
>>>> <[email protected]>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']
> ]
> }
>
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 [email protected] <javascript:_e({},
> 'cvml', 'puppet-dev%[email protected]');>.
> 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.
>
--
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/CAMJiBK6xuErMc3bhv2SJcKvk2BeL-RYUb2XYx1KYuNu1PzvfWw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
