From owner-freebsd-hackers Sun Jan 25 11:38:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA08459 for hackers-outgoing; Sun, 25 Jan 1998 11:38:15 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.119.24.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA08441 for ; Sun, 25 Jan 1998 11:38:04 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by ns1.yes.no (8.8.7/8.8.7) with ESMTP id TAA23105; Sun, 25 Jan 1998 19:37:51 GMT Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id UAA18548; Sun, 25 Jan 1998 20:37:50 +0100 (MET) Message-ID: <19980125203750.05884@follo.net> Date: Sun, 25 Jan 1998 20:37:50 +0100 From: Eivind Eklund To: Nate Williams Cc: Eivind Eklund , Andreas Klemm , hackers@FreeBSD.ORG Subject: Re: why not CVS server support ? References: <19980125175618.10691@klemm.gtn.com> <19980125183247.09801@follo.net> <199801251932.MAA28784@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88e In-Reply-To: <199801251932.MAA28784@mt.sri.com>; from Nate Williams on Sun, Jan 25, 1998 at 12:32:29PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk On Sun, Jan 25, 1998 at 12:32:29PM -0700, Nate Williams wrote: > > > Hi ! > > > > > > Why don't we support cvs server in the base OS ? > > > > (I assume you mean the cvs pserver mode?) Why would we want to? > > And what gives you the impression we don't support it? Andreas' mail ;-) I wouldn't have paid much attention if somebody disabled it (as it is dysfunctional and a security hole), so I assumed that was what he was talking about. > > pserver mode has had a few security violations in the past, and it > > wouldn't surprise me if has been turned of for that reason. > > It takes a bit of work to make pserver mode secure, and those security > precautions simply weren't taken since the remote CVS stuff doesn't work > well enough to use it on a regular basis. The only way I've seen of making it _fairly_ secure is to run it in a chroot()ed environement. With the number of other security problems it has had (allowing remote execution), I wouldn't consider that secure, either - any kernel security hole that can be exploited by a user program could still be abused. Read-only access in a chroot()ed environement is supposed to be fairly secure, but I still wouldn't trust it. Eivind.