>>> On 12/22/2005 at 2:18 am, in message <[EMAIL PROTECTED]>, Brian Candler <[EMAIL PROTECTED]> wrote: > On Wed, Dec 21, 2005 at 01:16:53PM -0700, Brad Nicholes wrote: >> <Directory /www/mydocs> >> Authname ... >> AuthBasicProvider ... >> ... >> >> Require user John >> <RequireAll> >> Require Group admins >> Require ldap-group cn=mygroup,o=foo >> <RequireOne> >> Require ldap-attribute dept="sales" >> Require file-group >> </RequireOne> >> </RequireAll> >> </Directory > > So if I write > > <Directory /www/mydocs> > Authname... > ... > Require Group admins > Require ldap-group cn=mygroup,o=foo > </Directory> > > then from your example I think you're saying there is an implicit > <RequireOne> around that, yes? If so, I think it would be better if it were > implicitly <RequireAll>. Otherwise it's easy to write an insecure > configuration accidentally (you think you've written Require A *and* B, when > you've actually written Require A *or* B)
Yes, there is an implicit OR operation. Mainly because that is how it works today if you include multiple 'Require' directives. So in order to remain as backwards compatible as possible and not pull any surprises, it should probably remain an OR operation. > > What happens if I mix Require and Reject > - within a <RequireAll> section > - within a <RequireOne> section? > > i.e. is 'Reject ...' exactly equivalent to 'Require Not ...', or is it more > complex than that? > > Will there be <RejectOne> and <RejectAll> as well? That is, I think you > need NAND and NOR, or at least NOT around a group, to be able to build any > desired boolean combination. > To be honest, I haven't given 'Reject' a lot of thought yet. It was an idea that was floated during our discussion at ApacheCon and I have been focused more on the authz provider conversion and reworking the 'Require' directive. My gut feel is that the 'Reject' directive will be equivalent to 'Require not' as you suggested and that it will be folded into the same <RequireAll>, <RequireOne> logic as the 'Require' directive. Basically with the new authz provider conversion, each provider basically returns a boolean value, AUTHZ_GRANTED, AUTHZ_DENIED. I see reject doing the same thing based on what the arguments are. Therefore I believe that there wouldn't really be a need to implement a <RejectOne>, <RejectAll>. 'Require' and 'Reject' should be able to be mixed within the proposed configuration logic. > Anyway, this framework does seem to be a lot more flexible and easier to > understand that the current one, especially if the 'Order allow,deny' and > 'Order deny,allow' stuff is eliminated :-) > > Regards, > > Brian. :) Brad
