On Thu, Nov 7, 2013 at 5:26 PM, Brian Stark <bdst...@gmail.com> 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. > > 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. > With this case I think if we separate title from target, would it meet the needs? It would allow you to hit the same resource from several areas without a conflicting resource/name issue. > > 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. > > 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 puppet-dev+unsubscr...@googlegroups.com. > 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, 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/CAMJiBK78z6AoUzRhvGvDj2YpLELyPnKfp6K1u8aNNSvprVfbpA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
