Sorry to put things out of sequence but... putting the reply on top should make it easier to find :)
Thanks for your insight and it seems it is as I expected. The one question I do have, though, is would using a remote CVS repository (using pserver?) make the repository more secure if developers did not have direct access to the repository files? I haven't dug too much into CVS... just wondering if it's an option. Thx, Marc Thornton [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] To: Thornton, Marc Cc: [EMAIL PROTECTED] Sent: 10/15/01 6:34 PM Subject: Re: cvs or rcs permissions in a secure environment [ On Monday, October 8, 2001 at 19:01:54 (-0400), Marc Thornton wrote: ] > Subject: cvs or rcs permissions in a secure environment > > Okay, the issue: using an ACL to apply permissions on the directories and > due to ACL limitations, I'm forced to give group access to the files to all > developers. Unfortunately, developers with the right ACL permissions (and > maybe some without.. haven't checked) are actually able to go to the > directory (through their RCS symlink, for example) and delete the ,v files > that are in the repository! (and someone has done just that... luckily > there wasn't a whole lot in that section of the repository at the time). > This, of course, wipes out the repository itself. (I don't think anyone responded to this yet....) So go the limits of ACLs with RCS and CVS. If you must isolate some files from some developers then you must isolate those files in separate directories so that different access controls can be applied. Given the way RCS (and thus CVS) works there is no other way. When a commit is made to a file RCS (and CVS) create it by creating a new copy of the ,v file, adding the delta along the way. If all is successful the old ,v file is unlinked and the new temporary ,v file is renamed to take the place of the old one. This implies anyone with commit access to any file in a directory must have write access to the directory it is contained in, and this of course implies that any of those users can do the same to any other file in that same directory. -- Greg A. Woods +1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs