httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: AuthzMergeRules blocks everything in default configuration
Date Tue, 04 Nov 2008 01:14:22 GMT
Ruediger Pluem wrote:

> I was hoping that your patches would fix this, but sadly they did not.

   Ironically, the problem appears to have little to do with authz,
but rather authn.  The test httpd logs show it's failing to find
an htpasswd-type file in which to check the user's login and password.
That's because there's no AuthBasicProvider in the test config, and
the code -- since way back, I think -- defaults to the "file" authn
provider.

   Looking back in SVN it seems like that should have been the
behaviour for quite a number of years, but I confess I didn't dig
too deeply.  Nor did I try out the test suite with 2.2.x to see
if it succeeds as-is, and if so, why.  If it does, my hunch would
be that it succeeds because the suite doesn't actually use the normal
authn/z providers, but rather supplies its own module called mod_authany.c.

   That module contains two different alternative set of functions
based on an #if AP_MODULE_MAGIC_AT_LEAST(20060110, 0) which corresponds
to, I think, an attempt to just get it to compile after the authn/z
refactoring in trunk.  The log comment for r375595 is:

    - attempt to adapt for trunk aaa changes; this doesn't work
    but it does at least compile - not sure whether the problem
    is in this code or the aaa code.

   At any rate, my guess would be that it works (if it does) with
2.2.x because the module supplies its own raw check_user_id (i.e., authn)
and auth_checker (i.e., authz) hook functions which run as APR_HOOK_FIRST
and probably bypass all the stuff in the usual APR_HOOK_MIDDLE hook
functions of mod_auth_basic and mod_authz_file.  So the fact
that it doesn't specify any AuthBasicProvider never comes up because
it bypasses mod_auth_basic entirely.  Just a guess.

   At any rate, the patch below makes it run with trunk, and
properly too, in the sense that it uses mod_authn_core and
mod_authz_core to do the heavy lifting and just supplies a tiny
pair of authn/z providers.  But, this isn't really a perfect
solution because it's not really correct to put the authn provider
into the AP_MODULE_MAGIC_AT_LEAST(20060110, 0) block, since it
doesn't (I think) have anything in particular to do with that
change.  Sorry not to spend more time on this.

Chris.


Index: mod_authany.c
===================================================================
--- mod_authany.c       (revision 710145)
+++ mod_authany.c       (working copy)
@@ -5,6 +5,7 @@
    require user any-user
    AuthType Basic
    AuthName authany
+   AuthBasicProvider any
 </Location>
 
 #endif
@@ -19,6 +20,18 @@
 #include "ap_provider.h"
 #include "mod_auth.h"
 
+static authn_status authn_check_password(request_rec *r, const char *user,
+                                         const char *password)
+{
+    return strtrue(r->user) && strcmp(r->user, "guest") == 0
+        ? AUTH_GRANTED : AUTH_DENIED;
+}
+
+static const authn_provider authn_any_provider =
+{
+    &authn_check_password
+};
+
 static authz_status any_check_authorization(request_rec *r,
                                             const char *requirement)
 {
@@ -28,11 +41,13 @@
 
 static const authz_provider authz_any_provider =
 {
-    &any_check_authorization,
+    &any_check_authorization
 };
 
 static void extra_hooks(apr_pool_t *p)
 {
+    ap_register_provider(p, AUTHN_PROVIDER_GROUP,
+                         "any", "0", &authn_any_provider);
     ap_register_provider(p, AUTHZ_PROVIDER_GROUP,
                          "user", "0", &authz_any_provider);
 }

Mime
View raw message