On Thu, Nov 7, 2013 at 10:47 AM, John Bollinger <john.bollin...@stjude.org>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 puppet-dev+unsubscr...@googlegroups.com. > 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 puppet-dev+unsubscr...@googlegroups.com. 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.
