Re: [RFC Draft] ACL in CVS proposal

[<mi...@ac...>]

Having written a CVS ACL patch and used it extensively in a large
group, I have a few comments :-).

Some information from my experience:

* A version control system repository is like a filesystem, but does
  not map to a filesystem one-to-one.  Be careful making analogies
  to filesystems.

* 99.99% of file permissions/ownership are the same in a directory.  My
  patch does not have per-file permissions, and none of the users have
  ever asked for it, and in our group we have never needed it.

* 99% of permissions in a directory can be directly inherited from the
  parent directory.

* Development groups have a strong need for multiple users with
  independent access controls.

* Having groups of users that can be assigned permissions together (so
  you only have to maintain per-directory permissions for the group,
  not the individual users) is very helpful.

* Per-branch tag permissions are useful, not only globally in the
  repository, but also per-directory.  Designers use branch tags for
  sandboxes and to let outsiders do work without affecting the main
  branch, as well as having them for releases.

* The concept of an owner is useful, because someone needs to maintain
  the permissions, create branches for sandboxes, and someone needs to
  have ultimate responsibility that is easily identifiable.  In a
  large group, the administrators don't have the time nor the
  knowledge to maintain permissions.

* You need the concept of a CVS administrator.

* Default file permissions are very important.


I have the following comments on my patch:

* Permissions are on a directory only.  There is an option to allow
  the permissions to be inherited from the parent directory (put in
  because so many people demanded it).  I was planning to add the
  ability to block the propigation, I think this would cover pretty
  much everything and be the most convenient way to do it.  If I
  wanted to add per-file permissions, I would by default take the
  directory permissions and let the user override them per-file.  This
  would drastically reduce the amount of ACL information that would
  need to be stored.

* I was planning on adding per-tag permissions.  With permissions
  being inherited, it would be very easy to grant per-tag permissions
  to the whole repository for a user or group.  This would solve the
  acl-per-file and acl-per-branch problem.

* I don't have the concept of default file permissions, and it has
  been a big problem.  With file permissions that propigate, though,
  it may not be a big deal.  My group cannot currently propigate file
  permissions (because that would give world-read access to the
  repository and we have a few things that we don't want world-read
  for), but with the ability to block the propigation it would be ok.

* Be careful to name your ACL control files something that is not
  likely to conflict with the name of a directory.  I didn't do this,
  and it has been a small problem.  It would probably be best to start
  it with a period.

* If you want to be able to track what is done in the main CVS
  release, you don't want the changes to change too much of the
  mainstream CVS code.  I didn't do this at first, and quickly
  switched.


I have some more comments inline below.  But this is a good start for
discussion, and I agree in principle with most of what you have said.

-Corey

Alexey Mahotkin <al...@hs...> writes:

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

Analagous to read access.

> 
> 	- check revision in;
> 
> 	  Rationale: obviously, don't let somebody commit anything on
> 	  this branch;

Analagous to write access.

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

As long as it didn't apply to branch tags, I would make write access
allow tagging.

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

Remember that releases are not the only things that branches are used
for, they are also used for sandboxes, and other things, too.  I would
let the owner create branches.

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

It would seem a lot easier to test the ACLs with a shell script.  We
could still write them ahead of time, and you will probably need some
program to act like a one-shot inetd to do the testing, but that
should be easy.  Shell script, or perl or something like that, will be
much easier to manage since they do the things we need to do much more
easily (execute commands and compare strings).

> 
> 
> 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
> 
> _______________________________________________
> Cvs-nserver-devel mailing list
> Cvs...@li...
> http://lists.sourceforge.net/lists/listinfo/cvs-nserver-devel