Strict Access Control for CVS pserver-mode
a.k.a. Connecting CVS to LDAP

This page describes how to use strict access control for CVS.

This page also describes the option to automatically generate Access Control Lists via a cron job, by querying an LDAP server, and then distributing the ACLs to the production CVS-servers.

 

I used to maintain the internal CVS server at Netscape, which had approximately 3000 internal users, many of them all over the world.

We used LDAP to feed NIS, so that people authenticate against LDAP when they log in - at some point in time it became necessary to restrict CVS access to certain people only - rather than everybody with an LDAP entry.

CVS has no way to really restrict access to only a limited list of users. One could restrict access to directories within the repository through UNIX groups - but at that point, a user would have already established a connection with the CVS server via pserver-protocol. And the readers/writers mechanism is not sophisticated enough - it defaults to "everybody with a UNIX account" - a very broad list of users if you are in an internationally operating company.

So one day, inspired by PANIC!, I patched the CVS 1.10.8 source code, to check if a user who tried to connect via pserver-protocol, is indeed on an Access Control List. If s/he's not on that ACL, the user will get a "permission denied" and will not be able to access ANYTHING in the repository.

To automatically update the CVS ACL, I also wrote a PERL / perLDAP script which is run by cron, and which queries LDAP to update the above mentioned ACL, it then adds some people from an exception list to the ACL, and checks the ACL in to RCS for bookkeeping (yes, locally!), then it creates an MD5sum of the ACL, to check if something on the production CVS-servers changed, and finally it distributes the ACL to all the production CVS-servers via SSH -- it's quite elaborate and does a lot of PARANOYA checking -- please do read the script for more info/details. Well, it's just an example - you need to modify it for your specific needs.

This is of course a bit of a half-hearted job, compared to implementing live LDAP connectivity for CVS .. but it was much much faster to implement static ACLs which are updated via cron.. and it works like a charm in a large production environment.

Only two source files needed to be modified: cvs.h and server.c.

Download

To use CVS with strict access control, you can either:

CVS ACL HOWTO

Make sure that you start the ACL-enhanced cvs executable in inetd.conf and send inetd a HUP signal. I would recommend to copy the ACL-enhanced CVS executable to a separate location, e.g.: 
# mkdir /opt/admin
# chmod 755 /opt/admin

# mkdir /opt/admin/bin
# chmod 755 /opt/admin/bin
# cp cvs-1.10.8-acl /opt/admin/bin
# chmod 555 /opt/admin/bin/cvs-1.10.8-acl

Create the following directory structure, and ACL-file, all owned by root, and with access restrictions as follows: 

# su - root

# mkdir /opt/admin
# chmod 755 /opt/admin

# mkdir /opt/admin/etc
# chmod 755 /opt/admin/etc

# touch /opt/admin/etc/valid_cvs_users
# chmod 644 /opt/admin/etc/valid_cvs_users
The ACL file /opt/admin/etc/valid_cvs_users needs to contain each authorized user-id in a separate line.

Lock Mechanism

 In case you want to automatically update the CVS access control list via cron, or you want to update it by hand, you need to create (touch) the file /opt/admin/etc/valid_cvs_users.lock while the list is being updated. This will temporarily disable CVS-access.

Remove the lock-file immediately after updating the ACL.

Maintainer: Tilo Sloboda unixNOSPAM@unixgods.org
last update: 23 October 2002