You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Brad Nicholes <BN...@novell.com> on 2006/07/29 00:30:51 UTC
What does the Authz "reject" directive really mean...
There is a new concept (directive) that has been added to the authorization (access control) portion of the web server. This new concept is "reject". Basically what this directive does is allow you to specify conditions by which access or authorization is denied. The question I have is how binding should "reject" be when found within a hierarchy set of authorization rules? Given the following configuration for example:
Alias /pages /www/pages
<Directory /www/pages>
Reject ip 127.0.0.1
</Directory>
<Directory /www/pages/secure>
Authtype Basic
AuthName Something
AuthBasicProvider file
AuthUserFile /somewhere/usr.dat
<SatisfyAll>
Require valid-user
Reject user joe
</SatisfyAll>
</Directory>
In this case is the user granted or denied access to the following URL:
https://127.0.0.1/pages/secure
user: betty
betty would be a valid user and the user name != joe but the ip is 127.0.0.1. In other words if the authorization directives specified in both <Directory> blocks are OR'ed together then authorization would be GRANTED since the result of the second block is GRANTED. However if the blocks are AND'ed together or the "reject" directive is definitive, then the result would be DENIED. Under the current implementation the implied merge would be an OR operation resulting in access GRANTED. So I guess my question is, should "reject" be definitive? If a "reject" rule is ever encountered and satisfied within the logic of authorization, is access automatically denied no matter what any of the other rules might produce? I am leaning towards 'yes, access should be denied'.
Comments?
Brad
Re: What does the Authz "reject" directive really mean...
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 7/28/2006 at 5:06 PM, in message <44...@apache.org>,
Ruediger
Pluem <rp...@apache.org> wrote:
>
> On 07/29/2006 12:30 AM, Brad Nicholes wrote:
>> There is a new concept (directive) that has been added to the
> authorization (access control) portion of the web server. This new
concept
> is "reject". Basically what this directive does is allow you to
specify
> conditions by which access or authorization is denied. The question
I have
> is how binding should "reject" be when found within a hierarchy set
of
> authorization rules? Given the following configuration for
example:
>>
>> Alias /pages /www/pages
>>
>> <Directory /www/pages>
>> Reject ip 127.0.0.1
>> </Directory>
>>
>> <Directory /www/pages/secure>
>> Authtype Basic
>> AuthName Something
>> AuthBasicProvider file
>> AuthUserFile /somewhere/usr.dat
>>
>> <SatisfyAll>
>> Require valid-user
>> Reject user joe
>> </SatisfyAll>
>> </Directory>
>>
>>
>> In this case is the user granted or denied access to the following
URL:
>>
>> https://127.0.0.1/pages/secure
>> user: betty
>>
>> betty would be a valid user and the user name != joe but the ip is
> 127.0.0.1. In other words if the authorization directives specified
in both
> <Directory> blocks are OR'ed together then authorization would be
GRANTED
> since the result of the second block is GRANTED. However if the
blocks are
> AND'ed together or the "reject" directive is definitive, then the
result
> would be DENIED. Under the current implementation the implied merge
would be
> an OR operation resulting in access GRANTED. So I guess my question
is,
> should "reject" be definitive? If a "reject" rule is ever
encountered and
> satisfied within the logic of authorization, is access automatically
denied
> no matter what any of the other rules might produce? I am leaning
towards
> 'yes, access should be denied'.
>
> I guess we need something like the old satisfy any / satisfy all
here. In
> old speak satisfy any would have granted betty
> access whereas satisfy all would have denied it. As you cannot build
> <SatisfyAll> <SatisfyOne> blocks across different
> Directory / Location containers I think we need to have a directive
that
> decides how to merge (AND / OR) the authz
> result from the "parent" container with that from the current
container.
Agreed but the old 'satisfy any/all' is still too ambiguous and doesn't
really solve the problem. The purpose of 'satisfy all/any' was an
attempt to combine host access control with authorization. That has
already been accomplished in the new authz refactoring. It really
doesn't solve the problem of how to merge <Directory/Location> blocks at
different levels. In fact authz merging wasn't really necessary before
because there wasn't really any kind of boolean logic interpretation of
require statements in the old authz world. Essentially everything was
an OR operation.
What I am considering now is to make the 'reject' directive definitive
and must exists outside of any <satisfyall/satisfyone> block. If a
reject rule is satisfied at any level, the request is denied. I am also
thinking about adding a directive called AuthzMergeParent that will
indicate how it should inherit the authz from it's parent. For
example:
Alias /pages /www/pages
<Directory /www/pages>
Require host apache.org
</Directory>
<Directory /www/pages/secure>
Authtype Basic
AuthName Something
AuthBasicProvider file
AuthUserFile /somewhere/usr.dat
AuthzMergeParent AND
<SatisfyAll>
Require user joe
</SatisfyAll>
</Directory>
The 'AND' argument would instruct the directory merge to use an AND
operation with the parent (base). An OR argument would instruct the
merge to use an OR operation and finally NONE would instruct the merge
to disregard any authz from the parent. If the directive is missing,
the default will be an AND operation.
Brad
Re: What does the Authz "reject" directive really mean...
Posted by Ruediger Pluem <rp...@apache.org>.
On 07/29/2006 12:30 AM, Brad Nicholes wrote:
> There is a new concept (directive) that has been added to the authorization (access control) portion of the web server. This new concept is "reject". Basically what this directive does is allow you to specify conditions by which access or authorization is denied. The question I have is how binding should "reject" be when found within a hierarchy set of authorization rules? Given the following configuration for example:
>
> Alias /pages /www/pages
>
> <Directory /www/pages>
> Reject ip 127.0.0.1
> </Directory>
>
> <Directory /www/pages/secure>
> Authtype Basic
> AuthName Something
> AuthBasicProvider file
> AuthUserFile /somewhere/usr.dat
>
> <SatisfyAll>
> Require valid-user
> Reject user joe
> </SatisfyAll>
> </Directory>
>
>
> In this case is the user granted or denied access to the following URL:
>
> https://127.0.0.1/pages/secure
> user: betty
>
> betty would be a valid user and the user name != joe but the ip is 127.0.0.1. In other words if the authorization directives specified in both <Directory> blocks are OR'ed together then authorization would be GRANTED since the result of the second block is GRANTED. However if the blocks are AND'ed together or the "reject" directive is definitive, then the result would be DENIED. Under the current implementation the implied merge would be an OR operation resulting in access GRANTED. So I guess my question is, should "reject" be definitive? If a "reject" rule is ever encountered and satisfied within the logic of authorization, is access automatically denied no matter what any of the other rules might produce? I am leaning towards 'yes, access should be denied'.
I guess we need something like the old satisfy any / satisfy all here. In old speak satisfy any would have granted betty
access whereas satisfy all would have denied it. As you cannot build <SatisfyAll> <SatisfyOne> blocks across different
Directory / Location containers I think we need to have a directive that decides how to merge (AND / OR) the authz
result from the "parent" container with that from the current container.
Regards
Rüdiger