bug-cvs
[Top][All Lists]
Advanced

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

Re: Suppressing log suppression (down with the -l switch)


From: Paul Edwards
Subject: Re: Suppressing log suppression (down with the -l switch)
Date: Fri, 30 May 2003 21:38:32 GMT

"Derek Robert Price" <derek@ximbiot.com> wrote in message 
news:mailman.7048.1054300079.21513.bug-cvs@gnu.org...
> >Suitable for use by a company that can "absolutely guarantee"
> >that they know exactly what happened to their source code at
> >every step of the way, not subject to the whim of cowboys.
> >
> >Unless there is already a plethora of integrity holes in CVS so
> >there's really no point?
>
> Well, yes and no.  A knowledgable sysadmin can nail down the permissions
> & access pretty tight if they want, but out-of-the-box pserver is pretty
> vunlnerable to a malicious attack.

Ok, first of all I think CVS should be free-for-all out-of-the-box,
as the last thing you want to do when evaluating a new product
is to set up 50 config files.  CVS is great.  As soon as you run it
it says "you haven't set $CVSROOT" and the second thing you
are told when you run it is "you haven't created $CVSROOT/CVSROOT",
you should run "cvs init".  And from there you can either do a mkdir
or "cvs init" and everything works.  It's excellent.

It means I can send people a single cvs executable and say
"rather than run diff3 manually on every file, type in the
following commands...".

However, I think there should be a special bit in the README
saying where to go to make it secure.  Where it says "see INSTALL
for full info" it should say "and if you're an administrator wanting
to make CVS secure, see section 'security' in the manual", or
depending on how many things there are you need to do, maybe
even include that in the README, ie briefly (in 5 lines if it can
be done):

1. After creating $CVSROOT, before doing the "cvs init", put it
into a special group, perhaps "cm".
2. Do a chmod g+s $CVSROOT
3. Run cvs init.

> >  But I'm not aware of any myself (not
> >that I've looked).  I can remember a very long time ago I used
> >to have to disable the admin command to stop people from
> >being able to do things like remove revisions.  I don't know if
> >use of that command is now able to be restricted.
>
> If a cvsadmin group exists on the server, only users who are members of
> the group may run `cvs admin' commands, with the exception of -k in
> 1.11.x and with the exception of any commands specified by
> UserAdminCommands= in the CVSROOT/config file in 1.12.x.

4. Create a $CVSROOT/CVSROOT/cvsadmin and put the administrator's
userid in it.

> >Where I'm working at the moment, I'm a programmer, not CM,
> >so I don't have to worry about security risks, the entire
> >repository can be wiped out by my colleagues any time they
> >want.
>
> Well, that's what tape backups are for.  Even friendly colleagues have
> been known to call `dirname` on a path in a script one too many times
> before running `rm -rf $path` as root.

I'm actually thinking of making the repository under control of
our sys admins so that even I need to go through them to manipulate
it, which is not a common occurrence.  Although I'm not keen on
being stuck requiring their intervention when I need to ship
something out of hours.  That's the problem with management
not officially recognizing the new methodology.

BFN.  Paul.




reply via email to

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