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