Repository Permissions

CVS does not require any particular repository permission scheme – it can handle a wide variety of permission arrangements. However, to avoid getting confusing behaviors, you should make sure your repository setup meets at least the following criteria:

• If a user wants any kind of access at all – even read-only access – to a given subdirectory of the repository, she usually needs file system-level write permission to that subdirectory. This is necessary because CVS creates temporary lock files in the repository to ensure data consistency. Even read-only operations (such as checkout or update) create locks, to signal that they need the data to stay in one state until they're done.

  As noted in Repository Administration, you can get around this writeability requirement by setting the LockDir parameter in CVSROOT/config, like this:

            LockDir=/usr/local/cvslocks
       

  Of course, then you would need to make sure the directory /usr/local/cvslocks is writeable by all CVS users. Either way, most CVS operations, including read-only ones, are going to require a writeable directory somewhere. By default, that directory is the project's repository; if you're very security conscious, you can change it to be somewhere else.

• Make sure the CVSROOT/history file is world-writeable (if it exists at all). If the history file exists, most CVS operations attempt to append a record to it; if the attempt fails, the operation exits with an error.

  Unfortunately (and inexplicably), the history file is not born world-writeable when you create a new repository with cvs init. At least with the current version of CVS, you should explicitly change its permissions after you create a new repository (or just remove it, if you want to disable history logging entirely).

  (This problem may go away – I just now submitted a patch to the CVS maintainers that makes the history file world-writeable when you initialize a new repository. So perhaps if you get a more recent version of CVS than the one available now (September 1999), it won't be a problem for you.)

• For security purposes, you almost certainly want to make sure that most CVS users do not have Unix-level write access to the CVSROOT directory in the repository. If someone has checkin access to CVSROOT, they can edit commitinfo, loginfo, or any of the other trigger files to invoke a program of their choice – they could even commit a new program if the one they want isn't on the system already. Therefore, you should assume that anyone who has commit access to CVSROOT is able to run arbitrary commands on the system.