Access Control in CVS

This page is about controlling the access which various users have to a CVS repository, with a focus on proposed changes to CVS. We also have a user-level page which introduces the subject and suggests what one can do with a vanilla CVS.

Here is a patch which adds access control lists implemented in CVS. Something of this sort is more powerful than unix groups, operates on the level of CVS usernames, and also has more potential to be expanded to offer finer grained access control (for example, different access control for "cvs tag" than "cvs commit").

I'm not sure what I think about trigger-style interfaces, such as the existing commitinfo and taginfo (or future extended versions thereof), compared with providing access control directly (as in the above patch). I guess the hardest part seems to me to be figuring out what operations are subject to control - that could be done once and then the same set of controls offered via triggers, direct access controls, and/or other variants.

Closing the holes which allow remote users (who are not read-only users) to run programs on the CVS server is, of course, important for most schemes to allow tighter access control (including commitinfo-based ones for example). For things like -i and -u in the modules file, I suppose there could just be a setting to disable those, as we already do for read-only users (serve_update_prog in server.c). Of course, would need to restrict write access to CVSROOT (commit/admin/&c). Anyone know of other holes? I'm not thinking of others.