httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthijs van der Klip <>
Subject RE: [users@httpd] nested htaccess files in conjuction with allow/deny
Date Wed, 23 Jun 2004 06:04:19 GMT
On Tue, 22 Jun 2004, Joshua Slive wrote:
> Start by reading the last paragraph of:
> and perhaps:

Ah, thanks. I could not find any information like this in the 1.3 section. 
I suppose 2.0 handles this similar to 1.3.

> Since the .htaccess processing happens in a different phase, the Order 
> directive in httpd.conf does not apply.  Placing an Allow directive in 
> there probably resets order to its default "Deny,Allow" which resets the 
> access state to Allow from all.
> This is, perhaps, surprising behavior, but not entirely undecipherable.  I 
> guess the trick is to ALWAYS explictly specify the Order directive 
> wherever you use Allow/Deny.

An example copied almost directly (A and B from the examples) from

<Directory /mnt/docs/PHP/test>
        Options FollowSymLinks
        AllowOverride Limit
        Order Allow,Deny
        Allow from

<VirtualHost *>
        ServerName test.mydomain

        # Logs
        ErrorLog /mnt/logs/apache/test/error_log
        CustomLog /mnt/logs/apache/test/access_log vcombined

        # Access Control
        <Directory /mnt/docs/PHP/test>
                # Deny access by default
                # Grant access to specific adresses thru a htaccess file
                Options FollowSymLinks
                AllowOverride Limit
                Order Allow,Deny
                Allow from

        # Document Root
        DocumentRoot /mnt/docs/PHP/test

So no htacces here, just two different Directory sections each allowing 
access to a different IP-address.

Now when trying to access this virtualhost from access is denied. 
When trying to access it from (using curl on the webserver 
itself) access is granted. So the sections are indeed processed in the 
order <Directory>, <VirtualHost><Directory> but it does not do additive

logic. My guess is that use of any of the mod_access directives in a 
section resets all these directives to their defaults.

I had a look in the mod_access source code and looking at the module 
structure I noticed it has a NULL config merger:

module MODULE_VAR_EXPORT access_module =
    NULL,                       /* initializer */
    create_access_dir_config,   /* dir config creater */
    NULL,                       /* dir merger --- default is to override 
    NULL,                       /* server config */
    NULL,                       /* merge server config */
    NULL,                       /* handlers */
    NULL,                       /* filename translation */
    NULL,                       /* check_user_id */
    NULL,                       /* check auth */
    check_dir_access,           /* check access */
    NULL,                       /* type_checker */
    NULL,                       /* fixups */
    NULL,                       /* logger */
    NULL,                       /* header parser */
    NULL,                       /* child_init */
    NULL,                       /* child_exit */
    NULL                        /* post read-request */

>From what I understand from, 
this means:

'To do that, the server invokes the module's per-directory config merge 
function, if one is present. That function takes three arguments: the two 
structures being merged, and a resource pool in which to allocate the 

'As a note --- if there is no per-directory merge function present, the 
server will just use the subdirectory's configuration info, and ignore the 
parent's. For some modules, that works just fine (e.g., for the includes 
module, whose per-directory configuration information consists solely of 
the state of the XBITHACK), and for those modules, you can just not 
declare one, and leave the corresponding structure slot in the module 
itself NULL.'

I think this proofs mod_access does not do any additive logic and thus you 
can only initialize it anew and override all settings from a lower level.

Best regards,

Matthijs van der Klip
System Administrator
Spill E-Projects
The Netherlands

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message