subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: propositionl: patching mod_authz_svn to be used as an authz provider for apache 2.4
Date Wed, 23 Jan 2019 11:58:26 GMT
On 23.01.2019 11:42, Francisco L Fernandez Tortosa wrote:
> Hello,
> I am involved in a customer project to replace CVS with SVN. SVN was
> chosen against more popular alternatives like git, because it is a
> free, open-source, mature and, this was the main point, centralized
> version control system. Repositories are to be accessed through https
> protocol, served by apache httpd server 2.4. Some features of the
> actual CVS service had to be ported to the SVN setup. For example,
> normal users shouldn't be able to create top (first) level folders and
> files. The straight forward to implement that requisite was through
> path access cheking. But activate  mod_authz_svn implies breaking any
> other authz module, like for example mod_authnz_ldap, required for us
> to control repository access based on LDAP group membership, or having
> true read only service accounts for Redmine, to have just two examples.

How relevant is it to this discussion that I maintain a Subversion
server with mod_authz_svn, that uses LDAP group membership (with
mod_authnz_ldap) to have true read-only accounts? With no patches.

> Looking at the source code I have found that mod_authz_svn is coded to
> support apache 2.2 authn / authz instead of native 2.4 model. As I
> didn't consider it a major effort, I have dedicated a few hours to
> analyze and patch the code, resulting in a functional 2.4 authz
> provider. This way it can seamless combine with other authz providers
> like in this example:
> svn01:~/src/subversion-1.10.0/source/subversion-1.10.0 # cat
> /etc/apache2/vhosts.d/svn.d/repos/test.conf
> <IfModule mod_dav_svn.c>
> SetEnvif Request_URI ^/repos/test Repo_test=1
> CustomLog   /svn/logs/repos/test/access.log "%h %t -
> %{SVN-REPOS-NAME}e - %u - %{SVN-ACTION}e" env=Repo_test
> <Location "/repos/test">
>     DAV svn
>     SVNPath /svn/repos/test
>     AuthzSVNAccessFile /svn/config/auth/accessfile-test
>     SVNReposName "Repositorio de TEST"
>     AuthzSVNAuthoritative Off
>     AuthzSVNAnonymous Off
>     AuthMerging And
>     <RequireAll>
>     <RequireAny>
>       Require control-point "GuardiasRedes"
>       Require control-point "Administradores Servidores Horizontales"
>     </RequireAny>
>       Require svnpathaccess "Granted"
>     </RequireAll>
>  </Location>
> </IfModule>
> svn01:~/src/subversion-1.10.0/source/subversion-1.10.0 #
> The "Granted" argument to the "require svnpathaccess" line for the
> provider is just a placeholder / syntax sugar as all the info that the
> provider needs is provided through the directory level clauses
> AuthzSVNAccessFile, SVNReposName... etc.

What does your proposed 'svnpathaccess' do? From your configuration I
don't understand its purpose.

Here is an example of the configuration I mentioned above; it uses
mod_authz_core, mod_authz_user, mod_authnz_ldap and mod_authz_svn.

    <Location /repos/>
        AuthType basic
        AuthName "Example"
        AuthBasicProvider ldap

        AuthLDAPUrl ...
        # (rest of LDAP config omitted)

            Require valid-user
                    Require ldap-group cn=write,ou=group,dc=example,dc=com
                    Require ldap-group cn=read,ou=group,dc=example,dc=com
                    # More reader groups here  
                    Require ldap-group cn=write,ou=group,dc=example,dc=com
                    # More writer groups here

        DAV svn
        SVNParentPath ${SVN_REPO_DIR}
        SVNListParentPath on
        SVNPathAuthz short_circuit
        AuthzSVNAccessFile ${SVN_AUTHZ_FILE}

> The patched code suits our needs, but we are very concerned about
> support and maintenance. Would it be possible for the SVN dev team to
> integrate in the official code a patch like this and provide the
> module full apache 2.4 integration?.

Of course it's possible, once we agree on why it's necessary and how to
actually do it.

> Attached goes the  patch for your consideration. It is written against
> 1.10 code. Perhaps you should correct some white spaces in the patch
> to apply cleanly because security restrictions at the customer don't
> allow the employes or subcontractors to send any type mail
> attachments, and I had to copy it in the body.

First of all, please make patches from trunk. Your patch duplicates some
changes that are already in our code, so it doesn't apply cleanly, which
makes it hard to test and evaluate.

I also see that the patch adds quite a lot of new conditional code; I'd
like to understand if it's really necessary; that's not clear from
comments in the patch.

-- Brane

View raw message