[RFC Draft] ACL in CVS proposal

[Alexey M. <al...@hs...>]

ACCESS CONTROL LISTS FOR CVS (Proposal)
========================================

This document discusses the design and implementation of ACL (Access
Control Lists) for the cvs-nserver.

This document is open for comments, suggestions and modifications.  If
you propose change large enough, please, provide a rationale for it.

You can commit new revisions of it into CVS after discussion in
cvs-nserver-devel mailing list (available on
http://sf.net/projects/cvs-nserver/).

The design of ACLs is based mostly on UNIX-style filesystem
permissions, with additional list of specific privileges for each
file.


Primary Authorization Features
===============================

We need the following basic authorization features:

- the ACLs are assigned on per-branch, not on per-file basis. 

  Rationale: a very common task is "let support engineers commit
  patches to the stable branch, and not to the trunk, which is for
  main developers only";

  This should be considered from the very first days of development.
  Maybe it would not be implemented right from the start, but
  switching from "acl-per-file" to "acl-per-branch" would seem like
  hell to do.


- the basic operations that should be controlled for each branch are:

	- check revision out;

	  Rationale: don't let somebody see what happens on the
	  development branch.

	- check revision in;

	  Rationale: obviously, don't let somebody commit anything on
	  this branch;

	- tag (non-branch) revisions (this includes moving and
	  deleting tags);

	- create branches;

	  Rationale: let the Release Manager do her job, don't let
	  mere developers to mark releases;


- the basic operations that should be controlled for each directory
  are:

	- accessing the files and subdirectories in this directories;

	- modifying (checking in, tagging, creating branches, adding
	  and removing files, creating directories);

  Rationale: obviously, we need to handle simple and frequent cases:
  "give somebody read-only access to the repository", "don't let
  somebody access any files inside of a directory (with
  subdirectories).

- newly created directories automatically get the same access rights
  as their parent directory.

  Rationale: see the convenience of "BSD groups", see the abomination
  of "set group of creating user".

- each directory could have default access rights for each branch that
  are assigned to new files created within this directory on this
  branch.  Those access rights are automatically inherited from
  upper-level directories if needed.

  Rationale: obvious.  We somehow need a way to setup default
  permissions to newly-created files; for flexibility this should be
  done on a per-directory, per-branch basis.


- when checking the access rights, the directories are traversed from
  the top directory to the directory where the file resides;

  Rationale: obvious to anyone who has ever worked with filesystem
  permissions :)


- I don't think there is a need of concept for "owner" and "owner
  group" for each file.

  Rationale: default permissions for files in any given directory
  completely supersede the notions of owner/group.


This list is probably not complete, though I think I've covered the
essential parts.


Quality Assurance
==================

I (or someone who is particularly interested) will soon create a set
of tests for the proposed ACL semantics in the form of a .c-file with
a simple, human-readable syntax (even though the actual code is not
written yet, a-la Extreme Programming)

That way we'll have the tests ready when the actual code will be
created, and the ACL semantics will be very clear from those tests.

Also, no new feature will be added without a test written for it
first.  That way the usefulness of that feature could be proven, and
no regression will occur because of it.


Internal Structure
===================

I think that all ACL information should be stored into one single ACL
file in each directory in the repository.  Probably it'll be later
complemented with the corresponding ACL.db, for speed, but that's not
an issue currently (we could always refactor later).


--alexm