preliminary ACL support in cvs-nserver

[Alexey Mahotkin]

Hello,

ACL support in CVS has always been rather hot topic.  There are AFAIK
several alternative implementations of this, and there is an option of
using the filesystem-level ACLs.

We've did another implementation, hopefully more generic than every other
(by coincidence, it also supports SSL).

Question: why not use the filesystem-level ACLs? 

Answer: because the cvs-nserver ACL implementation does not work on a
per-file level.  It works on a "per-branch", "per-tag", and many other
levels:

  - e.g., it allows to let the support engineers commit on a stable branch,
  while main developers commit on a trunk;

  - e.g., it allows to let only the release manager make tags that specify
  the releases;

  - there are many more features that could not be solved using the
  filesystem-based ACLs;


The preliminary code is available from http://cvs-nserver.sourceforge.net/
We hope to prepare the fully-usable release in a month or two.


Here is the proposal (which is now not a proposal, but the description of
an actual implementation, though not all things are fully done yet).


Sorry, it's current 04:26 AM, so I'm somewhat out of sync.  Just there was
a strong need of a synch message to a place more public than the
address@hidden


Be prepared!  [Comments welcome]



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/).

$Id: acl-rfc.txt,v 1.1.2.3 2001/09/30 00:13:13 tyranny Exp $


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

We need the following basic authorization features:

- the ACLs are assigned on per-file-on-branch, not on per-file basis.
  Same goes for directories case.

  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";

  NB: In CVS you cannot do anything with a "file" (or directory) per
  se.  Even when you delete a file, you delete it only on a specific
  branch.  Although, file-level ACLs could be emulated with default
  ACLs, see below.

  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.


- "per-file" ACLs could be emulated with default ACLs: if a file has
  ACL on a trunk, and does not have ACL on a branch, then the ACL on a
  trunk are used for the branch.

  Rationale: often the developers working on a trunk and developers
  fixing bugs on a stable branch are the same people, and there is no
  need to setup different ACLs.


  NB: From now on when speaking about the "file", we mean "file on a
  branch", if it's not explicitly specified otherwise.  Same for a
  directory.


- of course, user groups are fully supported.

  In general, when we are thinking about the "user", we mean "user or
  group of users", if it's not explicitly specified otherwise.


- the basic operations that should be controlled for each branch in a
  project or for a file (that is, file on a branch) are:

        - check revision out (read access);

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

        - check revision in (write access);

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


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

        - accessing the files and subdirectories in this directory;

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

  Rationale: obviously, we need to handle two 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)".

  The same set of ACLs is used as "default file ACLs".  If the file in
  this directory does not have explicit ACLs, the directory ACLs are
  used instead.

  Rationale: indeed, the 99% of files in each given directory have the
  same permissions.  But, sometimes we need to single out one
  important file and harden its security.


- default subdirectory ACLs.  If the directory does not have
  explicitly specified ACLs, they are taken from its parent
  directory.

  Rationale: see the convenience of "BSD groups".


- 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 :) Also, this brings sane implementation of "default
  subdirectory ACLs".  Also, it greatly simplifies the recursive
  processing of repositories.


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

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

        - create branches;

  Rationale: let the Project Release Manager do her job, don't let
  mere developers to mark releases.  It doesn't seem worth the trouble
  to make "tagging" access control be on a per-file basis, because the
  keyword in "Project Release Manager" is "Project".


        - list of ACL administrators for this module, who can setup
        the permissions as they see fit.

  Rationale: why not per-directory administrators?  If there are say
  two distinct development group working on the same project, and they
  need one administrator in each group, why not let them have separate
  administrator for ./project/subsystem1 and ./project/subsystem2
  directories?  Answer: it seems better to create two modules:
  subsystem1 and subsystem2, and then to create an ampersand-module
  called 'project' that merges those two modules.

  Rationale: if administrators can setup only ACLs, and not to modify
  files in the repository, the security risks are greatly reduced.
  Surely, the attacks of kind "no one is allowed to checkin any file"
  could be tolerated "better" than attacks of kind "every file has a
  thousand junk revisions applied, and all branches are renamed to
  something funny".

  For that reason, users who are ACL administrators for this module
  could not appear in the file-level ACLs (such entries are ignored,
  and the special script could be written that checks the sanity of
  permissions in the repository).


- 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.  Also, the
  administrator should be the only one, so to speak.


- there is a notion of "repository administrator", who can modify the
  list of ACL administrators for each module, and doesn't do anything
  else (mostly, at least she doesn't have root access to all the files
  in the repository).


This list is probably not complete, though I think I've covered the
essential parts.  What is needed now: you should think up a real-life
case that you think is not covered in this text, and we will think
together if that case could be a) implemented by the above; b) needs a
whole new feature; c) could be scrapped and forgotten.


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

All of the ACL-related functionality is fully unit-tested and
(hopefully) feature-tested.

Always create test-cases for new code in acl/ subdirectory; always
create test-cases for new features in cvs binary itself.  One cannot
overemphasize the importance of this.

This has already helped me a lot during the development, and I think
it'll be crucial alongside, when the functionality will be extended.


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

Internal structure of on-disk ACL-related files is documented in the
acl-on-disk.txt (soon to be written).



--alexm