Lately I’ve been working on securing some web accessible resource, especially Subversion access to repositories through the Apache webserver. One aspect we found very difficult was to secure subversion access through our apache server, when we had a Active Directory server to authenticate against (I know..).

Apache have some directives such as “Require valid-user” which signals that a user has to be authenticated against some authentication provider. This is in most cases a standard “.htaccess” and “.htpasswd” combination which provides this. For small projects, this may be a working approach. However, in a large-scale organization where you want a dynamic handling of users and their access, then using groups to reflect the users access to resources may be a better working solution.

For one of our projects, we wanted all LDAP (AD) users to have read access, while members of certain groups have read and write access. We solved this with the following Apache config:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<Location /wicked_project>
   DAV svn
   SVNParentPath /var/svn/wicked_project
   AuthzLDAPAuthoritative off
   AuthType basic
   AuthBasicProvider ldap
   AuthName "Need to authenticate here"
   AuthLDAPBindDN "ldap_user@domain.net"
   AuthLDAPBindPassword secretPassword
   AuthLDAPURL "ldap://ad.domain.net/dc=domain,dc=net?sAMAccountName?sub?(objectClass=*)"
 
   <Limit GET PROPFIND OPTIONS CHECKOUT>
      Require valid-user
   </Limit>
   <Limit REPORT MKACTIVITY PROPPATCH PUT MKCOL MOVE COPY DELETE LOCK UNLOCK MERGE>
   Require ldap-filter |(memberOf=CN=Staff,OU=GROUPS,DC=DOMAIN,DC=NET) \
                (memberOf=CN=Wicked_project_rw,OU=GROUPS,DC=DOMAIN,DC=NET)
   </Limit>
</Location>

Another LDAP directive which can work if you only need one group to have read and write access is the “ldap-group” directive. However, in our case we needed multiple groups, which is not supported by the “ldap-group” directive.

To solve this problem we used “ldap-filter” with multiple group filters inside the same filter, and divide them with the boolean OR. I don’t know if there are any more elegant ways of achieving the same result, but this solved our problems.

Having a second look at this “ldap-fiter” directive, I see that it have a significant strength in terms of flexibility. However, one aspect I have not considered is the performance of this approach. Without looking in-depth into the mod_ldap apache module, I can guess that for each filter inside the ldap-filter directive, it have to make a query to the LDAP (AD) server to retrieve the wanted resource. So, for each group filter inside the ldap-filter, you need a call. In our approach, we need two LDAP queries. As you now may see, the more groups to filter, the more LDAP queries, hence the performance will degrade the more complex the ldap-filter is.

Every now and then I get somewhat annoyed by the fact that I add temporary or “unwanted” files to a subversion repository. These files may be just temporary files, like *.tmp, which has no value of being kept in a repository, or compiled python files *.pyc, etc.

The common characteristics is that they are generally unwanted, and that they can easily be removed from the SVN repository. A common approach towards this issue is to set a property named “svn:ignore” on a directory, or the whole directory structure. This can be achieved with this command:

$# svn propset svn:ignore "*.tmp" .

where the single-dot at the end signalize the standing directory. However, this must be performed for each subversion project, which can get annoying in time. I’ve recently discovered the possibility of setting global subversion settings for my own user. The per-user subversion settings file is located on $HOME/.subversion/config. In that file there is a section named “[miscellany]“, which holds a variable named “global-ignores”. This variable can hold multiple ignore statements which will apply for all the svn checkouts you may work on (given you are using this user).

This subversion setting file also contains many more exciting options, such as automatic properties which apply to certain files. Have a look at the end for the $HOME/.subversion/config file and notice some of the predefined settings.

A tip based on personal experience is to hook the current files to the global-ignores variable:

*.pyc # python byte compiled code
*.swp # vim swap file
*.tmp # general temp files