Bug #7705: Overhauling authorization system internals and interface
Insertion of default ACLs can be blocked by unrelated ACLs in auth.conf
|Affected Puppet version:||Branch:|
- For REST access, ACLs are tested linearly. Matching stops at the first matching ACL.
- When testing whether an ACL matches, the path, method, environment, and auth are equal peers; if any of them don’t match, the ACL isn’t relevant to the current request.
- The default ACLs get inserted AFTER all of the ACLs in the
- If a default ACL is duplicated and overridden somewhere in auth.conf, Puppet will not insert that default ACL.
And now for the problem, which is that when deciding whether to skip a default ACL, Puppet does not test whether the two ACLs would match the same requests. Instead, it just compares the path. Thus, the following ACL, intended to allow one authenticated host to inspect the pending certificate requests:
path /certificate_request auth yes method find, search allow magpie.lan
…will disallow all incoming certificate requests by overriding the default
certificate_request; auth no; method find, save; allow all ACL, even though the sets of requests they match don’t intersect at any point. This is bad, and seems magical enough that it’s tricky to debug.
Two tentative suggestions are that we can:
- Append all of the default ACLs all the time. Overridden ACLs will then work as expected, because lookup proceeds linearly with auth.conf getting the first shot; if you override a default, it’ll effectively mask the default because no requests will survive long enough to reach it. (The current don’t-insert behavior seems to be based around a mistaken belief that auth.conf works similarly to fileserver.conf.)
- Cease to append default ACLs except for the
path /; auth anydenial rule; ship a working auth.conf and expect that things will blow up if you delete it. We’ll need some way to restore a default ACL when users do something silly.