From owner-freebsd-audit Wed Aug 9 0:16:18 2000 Delivered-To: freebsd-audit@freebsd.org Received: from gateway.posi.net (c1096725-a.smateo1.sfba.home.com [24.20.139.104]) by hub.freebsd.org (Postfix) with ESMTP id 1A82E37BDCA; Wed, 9 Aug 2000 00:16:15 -0700 (PDT) (envelope-from kbyanc@posi.net) Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.9.3/8.9.3) with ESMTP id AAA19394; Wed, 9 Aug 2000 00:20:12 -0700 (PDT) (envelope-from kbyanc@posi.net) Date: Wed, 9 Aug 2000 00:20:11 -0700 (PDT) From: Kelly Yancey To: Kris Kennaway Cc: audit@FreeBSD.ORG Subject: Re: Update to patch(1) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-audit@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 1 Aug 2000, Kris Kennaway wrote: > On Sun, 2 Jul 2000, Kelly Yancey wrote: > > > > > Can someone please review the patches in PR 19642. They merge in many > > changes to patch(1) from OpenBSD. Specifically, they remove the standard > > mktemp race condition as well as fix some potential buffer overflows. > > Sorry for the delay. > > Some comments: > > * be consistent about sizeof(foo) vs sizeof foo (choose whichever the > surrounding file uses) > Yeah, unfortunatly the surrounding files aren't consistent either. :( The existing code flips back and forth between the two at will. > * system() is insecure - there's no point in making all the string > operations buffer-safe if you go and pass a user string to system() :-) > I can only assume that the original OpenBSD patches were more for consistency's sake. It can't hurt, though. :) > * mkstemp() + close() isn't a drop-in replacement for mktemp() since it > will leave tempfiles around if the program exits through an abnormal > channel (error condition, signal, etc). mkstemp() + unlink() is usually > okay if the program (or another program) doesn't need to reopen the same > file, although it needs more source-code modification. > Hmm. That is a good point and an interesting dilemma: without making some fairly intruisive changes I can't use mkstemp() + unlink(). So which is the lesser evil: the existing use of mktemp or risking leaving tempfiles with mkstemp()? > Kris > Thanks for reviewing these and I look forward to your comments. Kelly -- Kelly Yancey - kbyanc@posi.net - Belmont, CA System Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSD http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message