info-cvs
[Top][All Lists]
Advanced

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

Re: Converting from ext to pserver


From: Eric Siegerman
Subject: Re: Converting from ext to pserver
Date: Tue, 24 Apr 2001 19:22:20 -0400
User-agent: Mutt/1.2.5i

On Tue, Apr 24, 2001 at 05:01:53PM -0500, David D. Hagood wrote:
> David H. Thornley wrote:
> > Is there any way I can turn off non-pserver access, or detect
> > it when it happens?
> 
> What about marking the repository as not exported in your exports file?

Or if it's on a filesystem that must be exported for other
reasons, just rename it.  That'll make "ext" access blow up real
good.  But it won't help you if your users are smart enough to
figure out what happened and change their CVS/Root files (or just
check out a new sandbox) without telling you.

Better would be to make the repo un-world-readable, and point
inetd.conf at a private copy of cvs that's setgid to the group
the repo's in.

As I guess you know, CVS hasn't been security-audited and
probably (certainly?) has gaping holes ... but you're not trying
to implement *real* security, ie. to protect against malicious
attack; merely to guard against error.  (If real security was
your goal, you wouldn't be using pserver :-)

Just be sure the cvs binary is setgid to a group used exclusively
for that purpose -- that way, people won't be able to exploit it
to get access to anything *other* than the repo.

The setgid cvs should be a private copy so that it's not in
peoples' $PATH's, which would make the exercise pointless; also
to keep /usr/local/bin/cvs (or whatever) available for people to
use locally in their own private repo's, if any (not
project-related ones, of course! *shudder*  But for example, I
have a private repo for my standard collection of .profile files,
~/bin shell-scripts, etc. -- stuff which has no business being in
the company-wide code repository.)

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)



reply via email to

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