[Top][All Lists]

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

Re: CVS newbie - I want to make a new CVS installation secure...

From: Mark D. Baushke
Subject: Re: CVS newbie - I want to make a new CVS installation secure...
Date: Wed, 19 May 2004 01:44:50 -0700

Hash: SHA1

Flossie <address@hidden> writes:

> >>1) However the first real problem I have is that a CVSROOT folder
> >>appeared locally - this must have been created automatically in the
> >>/usr/local/cvsroot folder. This has all sorts of files with settings
> >>for controlling various CVS behaviour.
> >>a) I don't want CVS users to be able to change these
> > Use a commitinfo trigger. See
> >
> Good grief, maybe I'm missing the point here?


> I had a look - this feature implies that you can write some fancy
> script to verify that the code being committed confirms to all the
> rules we laid out in the config files in the CVSROOT folder. I.e do a
> ton or reg-ex stuff to verify that each file is ok?? That could be a
> huge amount of work. I simply want to 'lock away' from the user access
> to any config changes they may otherwise me able to make in the files
> in the CVSROOT folder.

In the commitinfo script, provide for a script that is run when
it is for a CVSROOT directory commit:


and have the $CVSROOT/CVSROOT/cvs_acls file installed per the
contrib/cvs_acls file that you can get from the version of

> > You will need to consider that CVSROOT/history and CVSROOT/val-tags
> > typically need to be updated by users, otherwise, sure you can make it
> > impossible for them to create a lock in the CVSROOT directory in which
> > case attempts to do a 'cvs checkout' will give them a potentially more
> > confusing message than you are trying to protect them from in any case.
> Probably not a CVS issue, but you may have some comments - TortoiseCVS
> docs seem rather out-of-date; many areas refer to 'checkout', but I
> have not seen 'checkout' once in any of the context-sensitive menus. A
> lot of what they suggest (WRTO checkouts) therefore seems unacheivable.

I have not used TortoiseCVS, but many folks seem to like it. You may
wish to contact an e-mail list for users/developers of that tool for

> >>3) Can I stop the general users from performing things like code
> >>branching? Stop them from removing files?
> > Yes. See
> >
> > for taginfo as well as the info on commitinfo from the link provided
> > in answer to #1.a.
> I cannot see any hint in this section as to how I can stop users from
> creating branches, removing files, etc. Nor can I see how it relates
> to commitinfo (unless you auto-create a tag when someone commits to
> CVS, but that's not what I'm wanting here).
> Perhaps you could elaborate?

The taginfo script will be able to determine who the user is that is
running the script and what the tag is that they are attempting to use
and disallow the commit by exiting with a non-zero return code.

        -- Mark

Version: GnuPG v1.2.3 (FreeBSD)


reply via email to

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