From owner-freebsd-security@FreeBSD.ORG  Wed May 18 14:15:03 2005
Return-Path: <owner-freebsd-security@FreeBSD.ORG>
Delivered-To: freebsd-security@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8D1C916A4CE; Wed, 18 May 2005 14:15:03 +0000 (GMT)
Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 032D943D62; Wed, 18 May 2005 14:15:02 +0000 (GMT)
	(envelope-from keramida@freebsd.org)
Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr
	[62.103.39.226])j4IEDIDD019356;	Wed, 18 May 2005 17:13:18 +0300
Received: from orion.daedalusnetworks.priv (orion [127.0.0.1])
	j4IEEu8p040408;	Wed, 18 May 2005 17:14:56 +0300 (EEST)
	(envelope-from keramida@freebsd.org)
Received: (from keramida@localhost)j4IEEuHJ040407;
	Wed, 18 May 2005 17:14:56 +0300 (EEST)
	(envelope-from keramida@freebsd.org)
Date: Wed, 18 May 2005 17:14:56 +0300
From: Giorgos Keramidas <keramida@freebsd.org>
To: Max Okumoto <okumoto@ucsd.edu>,
	Alexander Leidinger <netchild@freebsd.org>
Message-ID: <20050518141456.GB40240@orion.daedalusnetworks.priv>
References: <200505121545.j4CFjENu078768@repoman.freebsd.org>
	<20050512180743.6z1h22fldwksgw4w@netchild.homeip.net>
	<hfbr7ge2gu.fsf@multivac.sdsc.edu> <42897003.2090005@ucsd.edu>
	<20050517144446.gibxprydoosokw0k@netchild.homeip.net>
	<428A23A2.5080108@ucsd.edu>
	<20050518100548.h8r4qc59c08swoog@netchild.homeip.net>
	<hfacmt7wpj.fsf@multivac.sdsc.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <hfacmt7wpj.fsf@multivac.sdsc.edu>
X-Mailman-Approved-At: Thu, 19 May 2005 12:33:30 +0000
cc: freebsd-security@freebsd.org
Subject: Re: cvs commit: src/usr.bin/make job.c
X-BeenThere: freebsd-security@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Security issues [members-only posting]
	<freebsd-security.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>,
	<mailto:freebsd-security-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-security>
List-Post: <mailto:freebsd-security@freebsd.org>
List-Help: <mailto:freebsd-security-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-security>,
	<mailto:freebsd-security-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 18 May 2005 14:15:03 -0000

On 2005-05-18 01:41, Max Okumoto <okumoto@ucsd.edu> wrote:
> Your idea of using mkdtemp() can be fixed by putting a loop
> around the code. Each time around the loop would be expensive
> but we wouldn't be doing that to often anyway.
>
> loop:
>     mkdtemp(template)
>     mkfifo(tempalte + "/fifo")
>     if error remove temp directory, restore template and loop.
>
> Or better yet, if someone could create an equiv function in libc
> so I don't have to maintain it in make(1) :-)  Do any other
> programs need the ability to make a temp fifo?
>
> Personally, I don't think it is a risk, but I wanted other
> peoples opinions, before I tried to fix a non-issue. :-)

Does this really need to be of the form DIR/fifo ?

I haven't looked at the code that uses the fifo at all, so I risk being
extremely out of topic here, but why wouldn't a temporary fifo created
with a name obtained from mkstemp() work too?

A directory won't be needed if the fifo name is created by mkstemp() and
then passed directly to mkfifo(2).

Then there is still a (small?) possibility for a race, but a subsequent
invocation of mkstemp() is almost guaranteed to work, unless mkstemp()
is severely broken.