On Thu, Nov 7, 2013 at 5:26 PM, Brian Stark <[email protected]> wrote:
> > > On Thursday, November 7, 2013 9:47:56 AM UTC-7, John Bollinger 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: >> >> 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'': >> # ... >> ; >> } >> >> >> >> John >> >> > This is incredibly important to me. I often have to manage domain user's > access to private keys stored in the certificate stores (i.e. > cert:\\LocalMachine\My\{thumbprint}) - in fact, this is my primary need for > any ACLs for Windows. As noted in the ARM, registry key access would be > nice, although I have not needed it. > I've added this for registry - https://tickets.puppetlabs.com/browse/MODULES-959 If you feel that one would be necessary for certificate permissions, I think that would be a good use case for an additional ticket on the MODULES project in JIRA. > > My need is to set multiple permissions on the same certificate from > multiple modules, which to this point is a terrible mess. I don't see > anything documented that would allow this scenario to work - adding to an > ACL defined defined in module A from module B. Since my primary use case > for ACLs is private key permissions, I will just through this out to noodle > on: Module A:Cert defines a certificate and installs it to LocalMachine\My > and creates an ACL with no ACEs. A, with some knowledge of the user > needing private key access to the cert in A:Cert adds to the ACL defined > there. Module B requires the same certificate and PK access defined in > A:Cert, so it includes A:Cert, but would also need to add to A:Cert's > defined ACL. > > The problem above has been my only issue that I have encountered in Puppet > that I have yet to come up with a graceful solution to. From reading the > ARM, I don't think this will solve it, but just wanted to through out a use > case that could be extended to file ACLs as well. > This is allowed with acls, with a note that this should be used with care because it could cause thrashing in reports - https://github.com/puppetlabs/puppetlabs-acl#same-target-multiple-resources > > Brian > > -- > 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/9eb5c708-cb80-4f0d-932d-d9227f75c47e%40googlegroups.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- Rob Reynolds Developer, Puppet Labs *Join us at **PuppetConf 2014 <http://puppetconf.com>**, September 23-24 in San Francisco* *Register by May 30th to take advantage of the Early Adopter discount <http://links.puppetlabs.com/puppetconf-early-adopter> **--**save $349!* -- 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/CAMJiBK4jBg69X5vVWNoD08eww2T4B1N3Qvc%2BwM6aOy5ZpvVY5A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
