httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <>
Subject Re: [PROPOSAL][DISCUSSION] Applying 'AND/OR' logic to the authz providers...
Date Thu, 22 Dec 2005 20:51:43 GMT

>>> On 12/22/2005 at 2:18 am, in message
Brian Candler <> 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
> 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
> understand that the current one, especially if the 'Order allow,deny'
> 'Order deny,allow' stuff is eliminated :-)
> Regards,
> Brian.



View raw message