On Tue, Oct 29, 2013 at 4:53 PM, John Bollinger
<[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.


>
>
> 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/a808b3cf-d51d-4a2c-b9b5-eaa20016dba3%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/CAMJiBK5CfnC4v4vuwnQuCi%3DUiBce2gG0dPzJnAvjXKdu5w%2BO0g%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to