NetBSD Problem Report #38230

From kre@munnari.OZ.AU  Wed Mar 12 14:22:06 2008
Return-Path: <kre@munnari.OZ.AU>
Received: from ( [])
	by (Postfix) with ESMTP id 28A2A63B8E3
	for <>; Wed, 12 Mar 2008 14:22:06 +0000 (UTC)
Message-Id: <>
Date: Wed, 12 Mar 2008 21:20:36 +0700 (ICT)
From: kre@munnari.OZ.AU
Subject: pkgtools/pkg_comp leaves turds in ${SANDBOX}/pkg_comp/tmp (+FIX)
X-Send-Pr-Version: 3.95

>Number:         38230
>Category:       pkg
>Synopsis:       pkgtools/pkg_comp leaves turds in ${SANDBOX}/pkg_comp/tmp (+FIX)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 12 14:25:00 +0000 2008
>Last-Modified:  Thu Jul 24 15:09:37 +0000 2014
>Originator:     Robert Elz
>Release:        NetBSD 3.99.15  (pkgsrc current within past 8 hours)
	Prince of Songkla University
System: NetBSD 3.99.15 NetBSD 3.99.15 (GENERIC-1.696-20060125) #8: Wed Jan 25 04:59:39 ICT 2006 i386
Architecture: i386
Machine: i386
	pkg_comp leaves empty mktemp(1) files in its sandbox when it

	Run pkg_comp to build anything...
		pkg_comp build pkgtools/pkg_comp
	would do.

	Then ls -l ${PKG_COMP_SANDBOX_BASEDIR}/pkg_comp/tmp

	Expect to see something like ...

jade$ ls -l
total 0
-rw-------  1 root  wheel  0 Mar 12 18:58 pkg_comp-064a
-rw-------  1 root  wheel  0 Mar 12 18:52 pkg_comp-083a
-rw-------  1 root  wheel  0 Mar 12 18:37 pkg_comp-165a
-rw-------  1 root  wheel  0 Mar 12 18:43 pkg_comp-166a

	(I had many more, but they're all basically the same, there
	should be one for each package build attempt, successful or
	not, since the last "pkg_comp makeroot")

	Apply the appended patch - one use of mktemp(1) was not
	following the pattern applied elsewhere in the script.

	But while I'm here, I don't really see the point of mktemp
	used this way - its intent is to safely create a file the
	script can use - in pkg_comp all the script ever does with
	the created file is remove it.   Given this, mktemp -u would be
	just as good (which isn't really much good), and quicker.

	But all this mess is mostly beause someone seems to believe
	there's some advantage in having shell scripts use names
	that end ".sh" - what's more, these are scripts that (normally)
	no human ever sees, they are created, executed, and removed,
	all quite quickly.

	If pkg_comp were to simply use the results of mktemp(1) as
	the script filename to use, it would all work just as well,
	and be much much safer.  Someone wanting to attack it now,
	can just create the .sh file as a symlink to whatever they
	want to overwrite (since the basename doesn't exist, the
	output from mktemp(1) is highly predictable), mktemp won't notice
	that file exists - true this is not easy in any case as pkg_comp/tmp
	is root owned and 755 mode, but if that's safe enough, then mktemp
	is not achieving anything, and the script might just as well
	create its own names)

	In any case, here's the patch for the forgotten "rm".
	(there's no real need to have the variable "prefix", it
	could have just used "script", but for consistency I just
	copied the pattern used elsewhere).

---	2007-10-28 07:28:06.000000000 +0700
+++	2008-03-12 20:58:09.000000000 +0700
@@ -764,14 +764,16 @@
-    local script
+    local script prefix


     # We assume filesystems are mounted!

     echo "PKG_COMP ==> Checking if pkg_install is up to date"
-    script=`mktemp $DESTDIR/pkg_comp/tmp/pkg_comp-XXXX`.sh
+    prefix=`mktemp $DESTDIR/pkg_comp/tmp/pkg_comp-XXXX`
+    rm "${prefix}"
+    script=${prefix}.sh
     init_script $script
     cat >> $script <<EOF
 cd /usr/pkgsrc/pkgtools/pkg_comp



Responsible-Changed-From-To: pkg-manager->jmmv
Responsible-Changed-When: Fri, 14 Mar 2008 23:59:56 +0000
Over to maintainer.

Responsible-Changed-From-To: jmmv->pkg-manager
Responsible-Changed-When: Thu, 24 Jul 2014 15:09:37 +0000


NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.