Hi all,
I posted recently (from a different account, I can't use the other one
today or tomorrow due to maintenance, grrr) about the above subject
line. I've investigated in the code of mod_authz_svn and worked out what
is going on and why my use case fails, and one way to solve it that I'll
present here (though I do not expect it to be accepted as a solution
since I'm pushing mod_authz_svn beyond what it was designed for).
The problem: mod_authz_svn doesn't work with LocationMatch (also known
as Location ~).
When given a URL to check access for the mod_authz_svn code splits the
given URL into a part containing the repository name and the remaining
part which is the relative path into the repository. Given a URL
something like this:
scheme://my.site.com/some/path/to/repos/path/in/repos..special
(I'll explain ..special later)
mod_authz_svn gets everything from the slash before some/path onwards.
It assumes that the repository name is the rightmost path component in
the section of the URL that matches the Location string. E.g. given a
Location string of:
/some/path/to/repos
and if mod_authz_svn receives this part of the URL:
/some/path/to/repos/path/in/repos..special
it strips from the start of the URL the Location string leaving it:
/path/in/repos..special
from which to work out the relative path into the repository. It can
then assume that the last URL component of the bit that was stripped is
the repository name, in this case "repos".
The ..special stuff has to be identified and removed so that the
relative path into the repository can be determined. I think this
"special" stuff (the code refers to it as special_uri) is SVN and/or DAV
identifiers. This is beyond the scope of this email and I couldn't
explain to anyone intereted what it is anyway since I don't know, I just
know the code tries to remove it when determining the relative URL.
Now for the problem part. mod_authz_svn works *unless* LocationMatch is
used and I have something like this:
<Location ~ "/some/path/to/repos/.+">
The call to ap_stripprefix() which removes the Location string from the
given URL now doesn't work at all - it fails to strip the string because
there isn't a match. This screws up all the logic that follows as it
cannot break the path into the components it expects to be able to.
The flaw in this process is to assume that the value of the Location or
LocationMatch block can be used as the part of the URL that can be
ignored and at the same time used to determine the repository accessed.
One way to solve this problem is to add this to the mod_authz_svn.c code:
--- /tmp/subversion-1.2.3/subversion/mod_authz_svn/mod_authz_svn.c
2005-08-08 22:53:19.000000000 +0200
+++ mod_authz_svn.c 2005-09-17 21:04:19.563287616 +0200
@@ -97,6 +97,10 @@
OR_AUTHCFG,
"Set to 'Off' to skip access control when no
authenticated "
"user is required. (default is On.)"),
+ AP_INIT_TAKE1("AuthzSVNParentURI", ap_set_string_slot,
+ (void *)APR_OFFSETOF(authz_svn_config_rec, base_path),
+ OR_AUTHCFG,
+ "Repository parent URI"),
{ NULL }
};
And in my Location/Location match block I do something like:
<Location ~ "/some/path/to/repos/.+">
AuthzSVNParentURI /some/path/to
Whereas normally the code would set base_path to /some/path/to/repos/.+
it now sets it to /some/path/to/repos and everything continues happily.
Another way of solving this would be to assume that it makes no sense to
have regular expression characters in the URL before the repository name
and so take everything upto the last slash before the first regex
character (or upto but not including the regex character if there is no
slash). However this makes assumptions about the valid set of regex
characters and that they cannot appear in a normal URL, which though
unlikely they can (e.g. + and $ both appear in the "safe" part of the
BNF for a URL while * and | appear in the "extra" part).
Another option perhaps is to trap the ap_stripprefix() failure and
behave differently somehow.
Thoughts?
I'm expecting someone to say don't allow LocationMatch. This would
prevent me being able to use mod_authz_svn to secure the ViewCVS browse
interface by URL and yet still be able to have the top level list of
repositories unprotected (and therefore free of the curse of a realm
username/password challenge dialog).
Of course then someone will say that I shouldn't be using mod_authz_svn
to secure anything but what it was intended to secure, i.e. the URL
space reserved for SVN repository addressing and *not* my ViewCVS URL
space. To that I can only say "fair cop guvnor" - although mod_authz_svn
is damn useful the way I'm abusing it :)
Ximon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Sep 17 22:11:27 2005