On Wed, Oct 30, 2013 at 9:12 AM, John Bollinger
<john.bollin...@stjude.org>wrote:
>
>
> On Tuesday, October 29, 2013 6:06:52 PM UTC-5, Josh Cooper wrote:
>>
>>
>> On Tue, Oct 29, 2013 at 2:57 PM, Rob Reynolds <r...@puppetlabs.com>wrote:
>>
>>>
>>> [...]
>>> 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?
>>
>>
>
> It would probably work, but I don't like it because it takes ACEs from
> being bona fide resources to being plain data objects merely masquerading
> as resources. Halloween isn't until tomorrow. Seriously, though,
> shoehorning an object into a context where it doesn't quite fit tends to
> lead to trouble; just look at the myriad historical and continuing issues
> around the edges of resource-like class declarations for a close-to-home
> example. On the more practical side, I would like to be able to declare an
> ACE and rely on it being applied, without regard to whether the general
> properties of the overall ACL(s) to which it is applied are also managed.
>
> I really think it makes sense to keep the (DSL view of the) data structure
> simple. That makes the resource types easier to understand and easier to
> integrate with external data sources, including via automated parameter
> binding. From that perspective I prefer to avoid relying on complex
> parameter value types, and I particularly dislike relying on resource
> references to hook things together, as references cannot currently be
> expressed in external data. Additionally, relying on resource references
> brings in all the issues around ensuring resources are declared exactly
> once. That can easily be avoided here, so why would you intentionally
> choose to *not* avoid it?
>
>
Josh and I researched some more, then discussed some possibilities at
length with someone from the modules team. It shaped how we were thinking
about defining the types quite a bit.
Interesting things to note:
- Modeling towards the real world, neither an ACE nor an ACL is
ensurable. The only type that is ensurable is a Security Descriptor (which
I was formerly collapsing into the ACL construct to reduce the number of
types), as Security Descriptor is the only artifact that can exist on its
own on a Windows system.
- Defining an ACE only approach, while very simple, has several problems
including:
- An identity can hold multiple ACEs on a singular resource. [ACL]
- It doesn't leave a place to define the owner of the resource.
[Security Descriptor]
- It doesn't really guarantee an order (rather a priority was
proposed that might help build an order). [ACL]
- It doesn't allow the ACE to be composed into multiple resources
(i.e. reusability) since it is coupled to the resource.
- It doesn't allow for specifying whether permissions are inherited
from parent resources. [Security Descriptor]
- It didn't help us define whether to purge non-managed resources.
- We're leaning towards some number of types and defined types (similar
to apache and mysql modules) so you can model to the level of detail
desired.
These things will be updated in the ARM proposal. So far this discussion
has brought out some great points. Once the ARM has been accepted I will
link to it so we can continue tearing it apart. :) Expect that to be in
the next day or so.
*More Detail*
"An identity can be in multiple ACEs on a singular resource" :
Let's take a look at a set of ACEs (that are part of the DACL in a security
descriptor) on an actual directory -
C:\>icacls "C:\windows"
C:\windows NT SERVICE\TrustedInstaller:(F)
NT SERVICE\TrustedInstaller:(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(M)
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
BUILTIN\Administrators:(M)
BUILTIN\Administrators:(OI)(CI)(IO)(F)
BUILTIN\Users:(RX)
BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
CREATOR OWNER:(OI)(CI)(IO)(F)
Successfully processed 1 files; Failed processing 0 files
Note BUILTIN\Administrators:(M) &
BUILTIN\Administrators:(OI)(CI)(IO)(F) specifies
that Administrators has two different explicit ACEs on C:\Windows. If they
were inherited, you would see an (I). The first specifies that
Administrators have Modify access to the directory. The second specifies
that Administrators have Full access to all files and folders inside that
directory, but not the directory itself.
>
> 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 puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/7024cede-9c4b-4e0b-8be5-4d7b12c56beb%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 puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAMJiBK60%2B3TRe3AyjbYmA7KgOWYthoapvYu%2BXMaKJ2rBn1gL-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
