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 [EMAIL PROTECTED] 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 _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
