Consider the following set:
acl {'c:/temp':
ensure => present,
permissions => [
{identity => 'Administrators', rights => [full]}
],
owner => 'Administrators',
inherit_parent_permissions => true
}
acl { 'temp_dir_module_name':
target => 'c:/temp',
ensure => present,
permissions => [
{identity => 'bob', rights => [read,execute]},
{identity => 'tim', rights => [read,execute]}
],
}
acl { 'temp_dir_module2_name':
target => 'c:/temp',
ensure => present,
permissions => [
{identity => 'bill', rights => [full], affects => self_only},
{identity => 'tim', rights => [read,execute]}
],
}
On Thu, Dec 19, 2013 at 5:04 PM, Rob Reynolds <[email protected]> wrote:
>
>
>
> On Thu, Nov 7, 2013 at 10:47 AM, John Bollinger <[email protected]
> > wrote:
>
>>
>>
>> On Wednesday, November 6, 2013 5:50:35 AM UTC-6, Rob Reynolds wrote:
>>>
>>> Here is the ARM - https://github.com/puppetlabs/armatures/blob/
>>> master/arm-16.acls/index.md
>>>
>>> Also have some questions listed at https://github.com/puppetlabs/
>>> armatures/blob/master/arm-16.acls/index.md#open-questions
>>>
>>>
>>
>> And now for the "continue tearing it apart" part :-). Issues that occur
>> to me upon first reading of the ARM, in no particular order:
>>
>> 1. I continue to maintain that it is inappropriate to use resource types
>> to model plain data. A resource type should model something that can be
>> applied in isolation to the target system. The proposed Ace type does not
>> satisfy that criterion. If there is a perceived need for the DSL to
>> support new or custom data types then that should be addressed as such, not
>> by trying to make custom resource types serve that role. Absent custom
>> data types, the types we have must serve.
>>
>
> I'm not sure we want to set some precedent of a data type that we don't
> have. So agreed.
>
>
>>
>> 2. The data types expected of all resource properties and parameters
>> should be limited to those that can be provided by hiera. Resource
>> references are not among those, as far as I am aware. If this principle is
>> not followed, and especially if it is not followed for essential parameters
>> such as security_descriptor.dacl and acl.permissions, then it will not be
>> possible to externalize the data for these resources.
>>
>
> This is the one that hit me as the biggest need we need to make sure we
> can serve and I spent some considerable time thinking and spiking out some
> concepts. I found what appears to work with hiera. Will show proposal in
> next email.
>
>
>>
>> 3. If security descriptors and/or ACLs may in the future support other
>> types of objects than files, then there is a potential for name (title)
>> collisions. Unlike many resource types, the ones documented in ARM-16 do
>> not appear to have any property separate from their titles by which to
>> specify the object to which they apply (compare Exec.command or
>> File.path). Moreover, even that might be enough. Puppet has no support
>> for compound resource identifiers -- which causes problems for Packages on
>> multilib systems, for example -- so although (type, identifier) may
>> distinguish (say) a specific security descriptor to a human, Puppet doesn't
>> know what to do with that. Instead, how about using URIs:
>>
>> security_descriptor {
>> 'file:/absolute/path':
>> # ...
>> ;
>> 'other_protocol:/looks/like/a/path'':
>> # ...
>> ;
>> }
>>
>> 4. It is inadequate and mildly inappropriate for the 'ensure' parameter
>> of the Acl resource type to direct whether its ACEs are present or absent,
>> as opposed to whether the ACL itself is present or absent. We already
>> covered that a Windows object may be without any DACL at all, with that
>> being a distinct state from having an empty DACL. It is unclear to me how
>> under ARM-16 to model the case in which an object has no DACL. Moreover,
>> it may easily be the case that one wants to enforce at the same time that
>> some ACEs are present an a given ACL whereas others are absent from that
>> ACL; I don't see how that can be modeled under ARM-16.
>>
>
> I tend to agree with this in retrospect. With ensure, we should be
> ensuring that on a particular security descriptor that is has a DACL with a
> particular set of ACEs. Breaking it out into three different types makes
> that process too complex. It would be better to start with a simple acl
> that allows us to treat it as a proper resource.
>
>
>>
>> 5. Inasmuch as multiple ACEs in the same ACL may be associated with the
>> same identity, I think ARM-16 does not present adequate means to identify
>> which ACEs to operate upon. I know I suggested earlier in the discussion
>> that ACEs be modeled as their own resources (though ARM-16 doesn't fully do
>> this), but every resource must have a unique, recognizable identity.
>> Otherwise, it is impossible to know how to sync the resource. I now think
>> that the abstraction needs to be a bit higher level: all the security
>> assertions pertaining to a given principal ("identity") for a given
>> object. It would also be possible to split that up into granted and denied
>> permission sets, or else into specific permission types (r, w, x, etc.),
>> but I don't see how to avoid grouping by principal.
>>
>> 6. ARM-16 does not address the issue of ordering the permissions
>> specified for a given object relative to unmanaged permissions present on
>> that object (when purging is disabled). Also, I suppose the intent is that
>> the managed permissions appear in the target ACL in the same relative order
>> that they appear in the Acl resource's 'permissions' array, but the ARM
>> does not actually specify that.
>>
>
> I thought we covered that, but from reading through I guess we didn't
> specify. I will make that update in the updated armature request.
>
>
>>
>> 7. ARM-16 does not provide a viable mechanism for access control
>> management to be decentralized across a manifest set. It requires ALL the
>> permissions that are to be managed for a given object to be known to a
>> single class. As the ARM currently stands, that issue cannot even be
>> mitigated by relying on externalizing the permissions data (see (2)).
>>
>
> You are correct. Would ensuring hiera works and decoupling the title from
> the target would alleviate most/all of this concern?
>
>
>>
>>
>> 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/ef2aeed9-115e-457f-b567-a96d2140e026%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
>
--
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/CAMJiBK4FTx%3DLugsYVB8%2Bmgq7x%3DUTDvP%2BVQuniC%3DkTjnKBUPWVw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
