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.

Now, lately I’ve been experimenting on some IR-software (http://lucene.apache.org), and for these experiments I needed to clear the internal page caching of I/O data. Basicly, whenever I open a file, then Linux caches that particular file, so that if I need it again later on, it will be available in “no-time”. For my experiments, I needed a “clean” cache for every run, and therefor needed to clear my cache.

After some Googling I stumbled upon this site: http://linux-mm.org/Drop_Caches. There was a lot of interessting stuff there, so I would recommend people to read it.

Basically, whenever you need to uncache something in your computer, you can (in Linux that is), write the following in a terminal:

This one below will free pagecache:

This one below will free dentries and inodes:

This one below will free both pagecache, dentries and inodes: