Ldap – Apache DAV SVN LDAP and AuthzSVNAccessFile

apache-2.2ldapmod-dav-svnsvn

I am working on a project where I have an ApacheDS containing all users and their group memberships. Group memberships are stored both as member attribute for each group and I have made a schema modification so I also have a memberOf attribute on each user making it trivial to check group membership when doing authorization. I need to give users access to Subversion repositories based on their group membership and have that up and running now.

However, my customer just told me he forgot to mention one "slight" detail when specifying the requirements. They apparently also have a few repositoires in which they need to have stricter requirements on certain subfolders. So to come up with a simple solution I thought I could simply combine my LDAP require directives with a AuthzSVNAccessFile directive.

Here is my config:

        <Location /TestClosedProject>
            SVNPath /repos/TestClosedProject
            SVNListParentPath on

            # Include shared LDAP settings, binddn, passwords, ldapurl etc.
            Include /svn/conf/ldapCommonSettings

            # LDAP Authentication & Authorization is final; do not check other databases
            AuthzLDAPAuthoritative on

            AuthName "TestClosedProject"

            # Admin group has full access
            Require ldap-attribute memberOf=cn=TestProject-admins,ou=groups,dc=somedomain,dc=somecountry

            # Members group has read-only access
            <Limit GET PROPFIND OPTIONS REPORT>
                    Require ldap-attribute memberOf=cn=TestProject-members,ou=groups,dc=somedomain,dc=somecountry
            </Limit>
    </Location>

This allows anyone in TestProject-members to read code in /TestProject and Test-admins have full access.

However, when I insert AuthzSVNAccessFile /svn/conf/TestClosedProject.svnAuth in the above config my require ldap-attribute directives can be overridden in the svnAuth file by specifying a user that does exist in LDAP but is not a member of neither the -admins nor the -members group.
Content of /svn/conf/TestClosedProject.svnAuth:

[groups]
supporters = jrf,agata
admins = fj,jrf
members = fj,jrf

[/]
* =
@members = r
@admins = rw

[TestClosedProject:/support]
@supporters = rw
@members = r

The problematic scenario is that

  • their LDAP is updated very frequently/automatically
  • while the svnAuth files are maintained by hand
    • so if e.g. an employee is fired/quits he will be removed from the TestProject-members/TestProject-admins group automatically – but due to some other internal systems he will continue to be a user in LDAP but with no "project-group" memberships. This will work fine as long as there is no svnAuth file giving him access to the project folders.
    • Since the svnAuth files are maintained by hand they will most often not be updated as regularly as the LDAP group memberships – and thus the fired employee will actually still be mentioned in the svnAuth file and thus have access to the repository, even though he is no longer a member in any of the required groups.

Is there any way to set this up so that only users in the members- or admins LDAP groups can be given access using the svnAuth file? Basically I just want to deny access to anyone not in either of those groups before delegating to the svnAuth file – is that possible – if so, how do i specify this?

Best Answer

Here's how I manage the repository access:

  1. Every repository has an "admin" directory, which contains the authz file
  2. I set up the authz file to limit access to the "admin" directory to the "owners" of the repository.
  3. I have a cron job check for changes in the "admin" directory, and copy out the authz file into the repository.

I don't do anything in the Apache config other that "require valid-user" (that way Apache only needs to be restarted when new repositories get added).

This way I offload all the maintenance of repository permissions to the owners of the repository. This may not directly address your problem, as it doesn't incorporate any LDAP groups, but this solution has worked for me for several years with hundreds of repositories.

Related Topic