[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: cvs or rcs permissions in a secure environment

From: Thornton, Marc
Subject: RE: cvs or rcs permissions in a secure environment
Date: Mon, 15 Oct 2001 20:44:09 -0400

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.

Marc Thornton

-----Original Message-----
From: address@hidden
To: Thornton, Marc
Cc: address@hidden
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
> due to ACL limitations, I'm forced to give group access to the files
to all
> developers.  Unfortunately, developers with the right ACL permissions
> maybe some without.. haven't checked) are actually able to go to the
> directory (through their RCS symlink, for example) and delete the ,v
> that are in the repository!  (and someone has done just that...
> there wasn't a whole lot in that section of the repository at the
> 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      <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird

reply via email to

[Prev in Thread] Current Thread [Next in Thread]