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 -- 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/CAMJiBK6DTvbd%2BLtkTrU-hi471AuQtN68K5RyMSUPNavuoqhK-w%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
