The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:
Prefer URI over certname when compiling node catalog
|Assignee:||Brice Figureau||% Done:|
|Affected Puppet version:||2.6.2||Branch:||http://github.com/masterzen/puppet/tree/tickets/2.6.x/5020|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
As discussed here: http://groups.google.com/group/puppet-dev/browse_thread/thread/45e287d5a0fb8585/e60645baa81b1a96
Since auth.conf (and default inserted rules when no auth.conf exists) provide enough security, it would be great to use the provided compiling URI key as the node name to compile, instead of using the provided SSL certname. It would allow monitoring or puppet-load to simulate any client with only one certificate by changing auth.conf:
path ~ ^/catalog/([^/]+)$ method find allow $1 allow puppet-load.domain.com allow monitoring.domain.com
#4 Updated by Matt Robinson over 5 years ago
- Status changed from In Topic Branch Pending Review to Code Insufficient
Brice, this does allow you to do what you want, but for some reason it breaks security. You say
This is safe because the default auth.conf (and default inserted rules when no auth.conf is present) only allow the given connected node to compile its own catalog.
However, when I tested this with the default auth.conf I was able to get catalogs other than the one for the connecting node. Not sure why. Without the patch:
err: Forbidden request: localhost(127.0.0.1) access to /catalog/othernodename [find] at line 93
#5 Updated by Matt Robinson over 5 years ago
- Status changed from Code Insufficient to Ready For Checkin
Looks like I messed up testing the #5020 patch because the helper script I was using to start the puppetmaster was copying an overly permissive auth.conf in. This was a relic of when I was documenting the REST API and wanted to not have to worry about security rules. I was testing the 2.6.x branch without this auth.conf on a different machine, so that’s why it looked like your branch introduced the permission problem.
So +1 to this patch.
On Tue, Oct 26, 2010 at 3:13 AM, Brice Figureau firstname.lastname@example.org wrote:
This is strange because this authorization check is done way before the catalog compilation terminus is involved (where my modification is).
This is confused me too. I should’ve followed code to see how it could have gotten by the early authorization.
How did you perform your tests?
Using curl to do the requests Using a script to start the puppetmaster (this is where my problem was)