Managing CVS access with POSIX Access Control List

Usually, in order to make access to a CVS repository less susceptible to damage from a malicious user, a separate account is required for each user, using a restricted shell in a chrooted environment. The method of CVS access control described in this article would still allow a user with write access to the repository to destroy files and lock out other users, but it allows for read and write privileges to be separated without the need for additional user accounts. ACLs could also be used in addition to the restricted shell methods, discussed elsewhere, to allow separated read and write control.

Posix 1003.1e Access Control Lists, though abandoned by IEEE before becoming a standard, are implemented in several operating systems, including Solaris, IRIX, and Linux (see http://acl.bestbits.at for Linux ACL support), and offer a powerful means of creating finely-tuned permissions on top of the traditional UNIX read/write/execute bits.

Considerations in placement of the repository

For your repository to be functional you will need, at a minimum, a directory for the repository itself and a directory for the lock files. Since you may want to create restricted/chrooted shell access for some accounts, perhaps in addition to Access Control Lists or for an anonymous account, you may want to put these both in the same root directory, along with a bin directory. Something like /cvs/repository, /cvs/locks, and /cvs/bin. Accounts could then chroot into /cvs and run a statically compiled cvs in /bin.

As always, the amount of space available on the repository's filesystem is something that should be matched to the projected usage. Quotas could possibly be enforced as well, though this could be counterproductive.

Setting up the repository

First, some new groups must be added to the system. root cannot make commits, so a non-root user must have access to the CVSROOT files in order to change configuration settings, and another group will be needed for the lock directory. In addition, two groups will be needed for each project managed with ACLs; one for read access and one for read/write access. This document will refer to these groups as cvs-adm, cvs-lock, project-read, and project-write.

The lock directory should be writable by the cvs-lock group, and have the sticky bit set to prevent users from deleting other users' lock files. In addition, on system with SystemV style group inheritance handling (such as Linux), the setgid bit should be set on the directory. So, on Linux the mode should be either 3775, or 3750, depending on how concerned you are about lock files being visible to users with no cvs access.

chown root:cvs-lock /cvs/locks ;
chmod 3775 /cvs/locks

Lock files will be created in the directory /cvs/locks/, where project is the project name along with any subdirectory names within that project. A problem with this is that when a new directory is created, it will be owned by the user who created it, so that user could then create trouble for other users using this lock directory. A partial solution to this problem is to have a cron job periodically fix the permissions on all directories in the lock directory.

Another problem with this setup is that a user could create a lock file and hold it forever, but this is a problem with nearly any configuration.

The cvs repository should be created through the usual means, with cvs init.

cvs -d /cvs/repository init

Following this, the group of the directory /cvs/repository/CVSROOT should be changed to cvs-adm. Then, as a non-root user with membership in cvs-adm, checkout CVSROOT, and in the file config, change the value of "LockDir" to the location of your lock directory (e.g., /cvs/locks). Commit the changes.

Adding a project

Now, the fun part. To add a new project, create the read and write groups for the project, and make a directory for the project in the repository. Change the group of the project directory to the write group, and set the permissions to allow group writing, and setgid group if necessary.

mkdir /cvs/repository/project ;
chgrp project-write /cvs/repository/project ;
chmod 2770 /cvs/repository/project ;

Then, add an acl entry to allow the read group read access.

setfacl -m 'group:project-read:r-x' /cvs/repository/project

Note that when using the IRIX chacl command, the regular read/write/execute information must be set as a part of the ACL as well, and must include a mask.

chacl 'u::rwx,g::rwx,o::---,g:project-read:r-x,m::rwx' /cvs/repository/project

And that's pretty much it. Now any user that is a member of of the cvs-lock and cvs-lock and project-read groups may do checkouts and updates, and any user that is a member of the cvs-lock and project-write groups has write access to the project.

Comments? Send them to [email protected]