Re: [PROPOSAL][DISCUSSION] Applying 'AND/OR' logic to the authz providers...

[Brian Candler <B....@pobox.com>]

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)

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.

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.

Re: [PROPOSAL][DISCUSSION] Applying 'AND/OR' logic to the authz providers...

[Brad Nicholes <bn...@novell.com>]

>>> On 12/22/2005 at 2:18 am, in message
<20...@uk.tiscali.com>,
Brian Candler <B....@pobox.com> 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