[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

mod_lua + mod_authz_svn: Problem with authenticating user and mod_authz_svn behaviour

From: Torsten Krah <krah.tm_at_gmail.com>
Date: Wed, 24 Jan 2018 15:49:36 +0100

Hi dev folks,

as per Stefans request on the user list i am going to repost my request
on this list to continue here (still need to open a ticket for this).
Please bear with me if something is unclear or not in a format which is
normally expected here, first time on this list, just tell me and i'll
try to adapt asap.

Back to topic:

The original issue with some background can be found here:

https://svn.haxx.se/users/archive-2018-01/0096.shtml

In short:

I did configure a custom lua hook to negotiate the user from mod_lua and
did not configure any other auth module like basic, form or digest.
Just the Hook, the AuthzSVNAccessFile configuration and a Require
valid-user directive.

<Location /svn-test-work/repositories>
  DAV svn
  SVNParentPath
"/home/tkrah/Development/src/subversion/subversion/tests/cmdline/svn-test-work/repositories"
  LuaHookCheckUserID /etc/apache2/auth.lua authcheck_hook early
  AuthzSVNAccessFile
"/home/tkrah/Development/src/subversion/subversion/tests/cmdline/svn-test-work/authz"
  Require valid-user
  SVNAdvertiseV2Protocol on
  SVNCacheRevProps off
</Location>

This does not work although i would expect todo so.

The problem found is that mod_authz_svn does expect a AuthType to be set
and it even looks for Basic-Authorization headers, which is a detail it
should imho not care about because Authentication can be done in
arbitrary ways, e.g. via those lua hooks and i would expect that the
authorization is still done from mod_authz_svn after r.user was set in
the configured hook - but the request gets denied even before the "Check
User ID" hook had a chance to kick in and provide that r.user to the
request.

I'll do not yet have an idea how to determine if auth is configured -
because for a unknown reason to me (i don't know the code well) - the
module wants to get that info and delegates that decision to the
condition:

ap_auth_type(r) != NULL

As described this is NULL, but the authentication hook from LUA is in
place so there is actually some authentication configured.
I'll still have a question running about that on the httpd list - what's
the best way to handle that and get that info (if we need that info at
all - i am not sure about that).

In the mean time my workaround is to set "AuthType Custom" in the httpd
configuration so that something is set to this variable and can continue
on that condition for now.
After that i'll applied the patch attached to remove the checks for the
Authorization header.

I'll recompiled the module and did run the basic_tests.py suite against
it - same results - with and without those header checks. But i am not
sure if there is even a test which checks that detail.

To me it seems ok to remove those checks because the authentication must
not rely on basic authentication only - but maybe i am wrong here and
there are some assumptions made to this authorization module which i may
break here.

TODO like written above is to omit the usage of the AuthType for this
condition:

authn_configured = ap_auth_type(r) != NULL;

but i got no idea yet what else should be used or if this condition
could be removed at all.

That's it :). Feedback welcome and appreciated.

kind regards

Torsten

  • application/x-pkcs7-signature attachment: smime.p7s
Received on 2018-01-24 15:49:45 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.