On Tue, Oct 29, 2013 at 2:57 PM, Rob Reynolds <[email protected]> wrote:

>
>
>
> 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.
>

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']
  ]
}

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].
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.

Reply via email to