httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject What does the Authz "reject" directive really mean...
Date Fri, 28 Jul 2006 22:30:51 GMT
   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


Mime
View raw message