info-cvs
[Top][All Lists]
Advanced

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

Re: disabling branch commit


From: Greg A. Woods
Subject: Re: disabling branch commit
Date: Fri, 17 Sep 2004 18:46:07 -0400 (EDT)

[ On Monday, September 13, 2004 at 12:49:58 (-0700), Mark D. Baushke wrote: ]
> Subject: Re: disabling branch commit 
>
> No. Checkout is based on standard UNIX filesystem permissions. Anyone
> who is able to 'see' the ,v files that comprise the directories you care
> about will be able to do checkouts. Some mitigation may be possible
> using the CVSROOT/config LockDir= directive to give you a different
> directory than the normal repository in which lock files may be created.

Note the same is true for controlling tag access too.

Any "ACL" implemented with any of the *info files is advisory only.

Only the underlying filesystem permissions have any true access control
capability, and of course at that level it's pretty much "all or
nothing" (at least w.r.t. all the CVS commands which modify the
repository).  You almost certainly also need to use a unique OS-level
user-ID for every human user or else there's no accountability possible
should any account get compromised.

Note also that read-only access control via filesystem permissions only
works if the the ":pserver:" is either totally avoided or at best used
only for read-only access where that control is _also_ enforced at the
filesystem level and if inetd starts "cvs server" as the read-only
user-ID directly (i.e. _not_ via root!).

> It is cheaper just to hire people you trust to work on your software or
> to setup a separate machine to be the repository master with a more
> restricted list of users if you have some contractual obligation to
> avoid having prying eyes looking at the sources.

Indeed!

-- 
                                                Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>




reply via email to

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