Issue #1875 has been updated by masterzen.
luke wrote:
> (Hit submit too soon.)
>
> Note that I added an extra wrapper around the auth check to make this error
> read a bit better.
>
> The only thing I've firmly established is that the problem occurs when my
> host (whose certname is other.madstop.com) asks for /catalog/phage (phage
> being its real name).
That's why I asked you a couple of days ago on #puppet why you used
Facter.value("hostname") for catalog retrieval, and Puppet[:certname] for facts
retrieval, because I was hitting the same issue. The real cause of the problem
is that the underlying authstore requires fully qualified names, but the
requests to catalog indirectors sends only the hostname, so in turns we're
trying to create a dynamic temporary allow("hostname"), which is forbidden.
Now that I think about it, it looks like a bug, as hostnames can clearly not be
unique among the various nodes connecting to a master (ie host1.domain1.com and
host2.domain2.com would get the same request, and maybe the same catalog...
after looking to the code, in fact no it works, because what matters is the
request determined node which hopefully uses the certname).
So it's just the catalog request that is wrong (the logic is OK), we should
move from /catalog/hostname to /catalog/fqdn or /catalog/certname.
What do you think?
If you're OK, I'll queue a patch to fix this issue.
----------------------------------------
Feature #1875: A REST Authorization file is needed
http://projects.reductivelabs.com/issues/1875
Author: luke
Status: Code Insufficient
Priority: High
Assigned to: masterzen
Category: network
Target version: 0.25.0
Complexity: Unknown
Affected version: 0.24.7
Keywords:
In the switch from XMLRPC to REST, we've exposed the lack of decent
authorization in the network interfaces.
Note that authorization is distinct from authentication, which is handled via
certificates.
Once a host is authenticated, we need some way of knowing what services or
aspects of services the host has access to. Current 0.24.x systems provide
multiple configuration files that cover some of this, notably fileserver.conf.
For arbitrary authorization, there is namespaceauth.conf.
We need something more generic that relies on our switch to REST, likely
providing authorization against URIs, possibly with some kind of mapping to
services.
E.g., we might have something like:
<pre>
path /
deny *
path /file
allow authenticated
path /certificate
allow unauthenticated
path /file/$host
deny *
allow $host # or something like that
</pre>
Clearly I haven't exactly thought this all the way through.
The main thing we need is something mirrors our existing default authentication
- defer to fileserver.conf for files, allow unauthenticated users to upload
certificate requests and download certificates, and allow authenticated users
to download catalogs.
It'd be nice to be able to fold fileserver.conf into this file eventually, I
think, but I wouldn't prioritize that.
Note that there are three fields to any authentication attempt: path/uri,
authentication status, http verb. Any configuration file would need to be able
to specify each of these in a given authorization specification.
It'd be best of all if we could find someone else's solution to this problem
and crib from them.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://reductivelabs.com/redmine/my/account
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---
