SetACLS aka How I Set Up CVSNT Permissions

Setup Access Control Lists using NTFS permissions and local groups. Author: Glen Starrett (glen at starrett dot name)

TO DO: This page needs to be renamed / reworked to better include information on the chacl and lsacl commands. They allow a different layer of access control.

NTFS ACL's Permissions vs. CVSNT's ACL functions

NTFS is file, group, and user based. This is they way NT administrators normally control file access to specific files and directories, based on the NT account user and the groups it is a member of.

CVSNT's chacl function is directory, user, and branch based. It allows the CVS repository administrator to set permissions based on which branches a user is working on. This allows you to prevent accidental commits anywhere but the branches that the developer is specifically allowed to commit on.

The author of this page uses both together: NT ACL's to prevent unauthorized access to the repositores, and CVSNT's ACL's to prevent the developers from committing to the wrong branch. However, this document only describes the NTFS ACL setup (the CVSNT ACL setup is easy but significant).

TO DO: Clarify this section, list alternative ways of controlling permissions (e.g. "commit" script).

Overview

CVSNT is very flexible and this represents just one way you could set up your CVSNT permissions. This is not so much a "How To" but rather a "How I Did It". I hope it is helpful to someone starting out with CVSNT. With all the options, setting up CVSNT quickly becomes confusing.

The SetACLS tool was written for convenience in setting up the permissions on CVSNT repositories by Glen Starrett, a CVSNT admin and user.

Always use caution and understand what you are doing before setting up security. I put this document together to help new administrators get a handle on one possible way to put together their security strategy but it should not be considered at all comprehensive.

Permissions Strategy Behind SetACLS

There are a number of ways you could set up permissions with this system. This is the way I did it.

• Users are permitted into the server and files via NT groups.

• Read-only users must be set up through CVSNT permissions (either the "readers" or "writers" file).

• This approach assumes that User Impersonation is on (it is by default).

• CVS Admins must either be in the local server's Administrators group or added to the "admin" file in the repository's CVSROOT (on the server, manually create and edit the file).

With this setup, the NT administrator sets up the repositories and NTFS file permissions initially, then the CVS repository administrators configure their respective repositories, authorize users to commit to them, and perform other administrative tasks.

CVSNT Install

CVSNT was installed and configured as follows:

• CVSNT Installed to d:\cvs\cvsnt

• Repository Prefix is d:\cvs\repositories

• CVS Temp directory is d:\cvs\temp

• Using sspi protocol (removed pserver and ext protocols, others present but unused)

• A few repositories created.

Bo Berglund's InstallationTips and DevGuy's installation guide are very informative and answer a lot of questions on installation. They also describe some of the different approaches possible in setting up the security, protocols, etc.

Setting Up Permissions

Setting up the Group, CVS, and File permissions.

NT Groups

These are the NT Local groups I created. There are two groups plus one per repository.

Special Group Rights And Permissions

The groups outlined above do not require any special rights (I don't believe even Log On Locally is required) with one exception.

Windows 2003 Server: If you plan on adding any scripts to CVS Server and it is running on Windows 2003+ server, you will need to make sure that the users have sufficient permissions on CMD.EXE and whatever will be running the scripts (e.g. perl.exe and libraries for PERL scripts, wscript.exe for VBS runtime, etc.). By default, regular users do not have permission to run CMD.EXE on Windows 2003.

CVSROOT files

The key CVSROOT files for controlling permissions with this setup are listed.

Note: When you add a user to either the admin or writers file, create the file with the base username (not "domain\username", just the "username" part) with one username per line.

The admin file should be created within the repository files on the server. With the NTFS permissions set up properly, it is unlikely that an unauthorized user could compromise the system but this isn't a file that the CVS Administrator needs to maintain anyway. Using the username jsmith as an example:

• Change directory to the repository CVSROOT with "d:" then "cd \cvs\repositories\XXXXX"

• Create (or append) to the admin file with "echo jsmith>> admin"

Note: There is NO space between "jsmith" and ">>" on the line above. Whitespace, even after the username, is significant and you can end up scratching your head for hours wondering why it doesn't work. You can also use a text editor, just remember that because whitespace is invisible it's easily overlooked.

The writers and config file are put under source control. To set up writers file, adding the user bsmith for example:

• Checkout the CVSROOT with "cvs -d :sspi:server:/XXXX co cvsroot"

• Change to cvsroot directory "cd cvsroot"

• Create (or append) to the file with "echo bsmith>> writers"

• Commit the changes with "cvs commit"

To set up LockServer (required):

• Checkout the CVSROOT with "cvs -d :sspi:server:/XXXX co cvsroot"

• Change to cvsroot directory "cd cvsroot"

• Edit the config file, uncomment the LockServer line to enable the LockServer

• Commit the changes with "cvs commit"

Note: You WILL lock yourself out of your own repository if you don't include your username in here before you commit the writers file! If you do accidentally, then on the server delete writers and writers,v from the repository CVSROOT.

File Permissions

These file permissions are set up by the SetACLS script. This setup allows all users to log history entries but only administrators can update the CVSROOT files.

Note: Administrators have read-only rights to most of the repository simply because they don't need more access. If it is required, they can of course grant themselves more rights.

SetACLS Script

The SetACLS script sets up the file permissions described in the table above.

Requirements

• Requires cacls from the Microsoft NT Resource Kit or xcacls from the Windows 2000 Resource Kit.

Note: This script was written using the NT 4.0 version CACLS, but CACLS is command-compatible with XCACLS. If you do want to use XCACLS with it, then simply replace all instances of "CACLS" with "XCACLS" in the script (or copy your xcacls.exe to cacls.exe).

What it does

• Stops CVS service

• Prunes the TEMP directory

• Re-creates the TEMP directory

• Assigns NTFS permissions based on the table above

• Re-starts the CVS service

Pruning and re-creating the TEMP directory is just for good measure, there shouldn't actually be any files in there after CVS has been shut down.

Using SetACLS

Note: You should review the SetACLS script before running it. The paths in the script are hard-coded to the way I have my server set up. Assuming you have a different configuration, then it shouldn't be too difficult to make the proper adjustments.

To use SetACL within the directory structure described above, just save the script into d:\cvs and run it. The directory it is placed in is important because all the paths within it are relative the executing directory.

SetACLS.cmd: SetACLS.txt Script last updated: Oct 1, 2003