Brad Nicholes wrote:
I'm not real excited about adding a new authz directive. Authn and authz are already very complex and adding a new directive to the mix will just help to confuse people even more.
That's a good point. Mostly the idea of an Accept replacement for Require came up as a way to distinguish pre-2.4 and 2.4 per-dir authz, and in case there were any "Require foo" directives which had slightly different meanings in the two contexts and which might therefore trip people up. If we can do without it, all the better.
I am OK with this one except for the reason that I mentioned before. By allowing authz to be inherited even when AuthzMergeRules is OFF is kind of a conflict. In other words, since AuthzMergeRules OFF implies an AND, 1 AND 0 should be 0 or no authz rather than inherited authz. However I could buy into this if it seems to make more intuitive sense to the user.
Well, I may be missing something, but what I envisioned was that AuthzMergeRules had three options: "Off" (i.e., inherited until overridden, the pre-2.4 default), "SatisfyOne", and "SatisfyAll". That would give administrators full control over how they wanted authz in different per-dir blocks to be merged. It seems to me we have three basic possibilities when it comes to merging authz across per-dir blocks, and the most common authz case to consider is going to be where security gets tighter as you move down the document tree. Imagine something like the following in a pre-2.4 configuration, where "admin" is not a member of "team": <Directory /htdocs> ## full access </Directory> <Directory /htdocs/team> ## anyone in "team" has access Require group team </Directory> <Directory /htdocs/team/admin> ## only "admin" user has access Require user admin </Directory> 1) The first option for 2.4 merging is to use OR logic (the current default in trunk). This leads to anyone in "team" having access to /htdocs/team/admin, I believe. I think I'd have to vote -1 against this, because it will lead to lots of previously secure configurations becoming insecure. Plus it would seem to increase the required number of directives (since you have to add "AuthzMergeRules Off" in each sub-<Directory>) to achieve what seems to me to be a typical configuration, i.e., increasing security as you go down the tree. 2) Another option might be to use AND logic. In this case, if I'm applying the logic correctly, no one would be able to access /htdocs/team/admin given the configuration above in a 2.4 context (since "admin" isn't in "team"). While more secure, this also seems counter-intuitive to me. Maybe -0.5? 3) Finally there's the pre-2.4 logic of overriding all previous authz. This would seem to be the most preferable option, since it ensures many pre-2.4 configurations will continue to work as expected, and I think also reduces configuration verbosity in typical cases. You were concerned, I think, about more complex configurations like this:
<Directory /www/pages> <SatisfyAll> Require ip 10.10.0.1 Require ldap-group sales <SatisfyOne> Require ldap-group ne-sales Require ldap-group sw-sales </SatisfyOne> </SatisfyAll> </Directory>
<Directory /www/pages/private> Require ldap-group marketing </Directory>
I would suggest that the default pre-2.4 logic of overriding previous authz when any authz is defined in a per-dir block is still reasonable as a default. Thus, only those in "marketing" have access to /www/pages/private, and they can access it from other addresses than 10.10.0.1. Even if this isn't what is desired, it's clear enough that an administrator can figure out what's going on and why the configuration isn't achieving the desired result. I'd propose giving the administrator the choice of both alternatives to the default logic. Instead of simply offering "AuthzMergeRules On", there would be two alternatives to the default "Off" condition. These would be "AuthzMergeRules SatisfyOne" (the OR logic) and "AuthzMergeRules SatisfyAll" (the AND logic). We might offer "Or" and "And" as synonyms for "SatisfyOne" and "SatisfyAll", respectively. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
