Issue #1875 has been updated by masterzen.
luke wrote: > It looks like this doesn't allow blanket statements like 'allow *' or 'deny > *'. > > I think that's an existing limitation, though, so I'm comfortable merging as > is and fixing that later. 'allow *' works fine. But deny * is not supported. This is because of the way authstore is working (ie it sorts allow rules before deny rules and finishes with an implit deny all). So basically, it has no sense to write: allow something deny * and a lone: deny * is equivalent to nothing. If we want something which would allow more complex scenarios, we need something ala Apache, with a directive to specify in which order ACE should be evaluated: order allow, deny allow this deny * Then deny would be applied after the allow. I thought about this, but in the end I think your system works, except we are tempted to add some "deny *" as catch-all rules, which is forbidden. And not that an "allow *" is treated _before_ any other rules, so that even if you have some denies after that they can't be reached. If you think we need to change this, then let's open a ticket, I'll be happy to work on this. > I ran through a basic list of tests and everything seems to work, so I'm > comfortable checking in as is. Thanks, I'll rebase to latest HEAD tonight. ---------------------------------------- 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 -~----------~----~----~----~------~----~------~--~---
