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)
<RequireAll>
Require valid-user
<Limit HEAD GET OPTIONS PROPFIND REPORT>
<RequireAny>
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
</RequireAny>
</Limit>
<LimitExcept HEAD GET OPTIONS PROPFIND REPORT>
<RequireAny>
Require ldap-group cn=write,ou=group,dc=example,dc=com
# More writer groups here
</RequireAny>
</LimitExcept>
</RequireAll>
DAV svn
SVNParentPath ${SVN_REPO_DIR}
SVNListParentPath on
SVNPathAuthz short_circuit
AuthzSVNAccessFile ${SVN_AUTHZ_FILE}
</Location>
> 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
Received on 2019-01-23 12:58:36 CET