From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <systemtap-cvs-return-2834-listarch-systemtap-cvs=sources.redhat.com@sourceware.org>
Received: (qmail 14427 invoked by alias); 2 Jan 2008 18:22:30 -0000
Received: (qmail 14411 invoked by uid 426); 2 Jan 2008 18:22:29 -0000
Date: Wed, 02 Jan 2008 18:22:00 -0000
Message-ID: <20080102182229.14408.qmail@sourceware.org>
From: fche@sourceware.org
To: systemtap-cvs@sourceware.org
Subject: src main.cxx
Mailing-List: contact systemtap-cvs-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <systemtap-cvs.sourceware.org>
List-Subscribe: <mailto:systemtap-cvs-subscribe@sourceware.org>
List-Post: <mailto:systemtap-cvs@sourceware.org>
List-Help: <mailto:systemtap-cvs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: systemtap-cvs-owner@sourceware.org
List-Archive: <http://sourceware.org/ml/systemtap-cvs/>
X-SW-Source: 2008-q1/txt/msg00000.txt.bz2

CVSROOT:	/cvs/systemtap
Module name:	src
Changes by:	fche@sourceware.org	2008-01-02 18:22:29

Modified files:
	.              : main.cxx 

Log message:
	Fix mkdtemp() umask issue
	
	Even though the mkdtemp() man page indicates that the
	directory will be created with always 0700 permissions,
	it is actually affected by the process's umask.
	
	So, if you run stap with an unusual umask it can end
	up creating the temp dir with permissions that
	staprun can't handle e.g.:
	
	$> rpm -q systemtap
	systemtap-0.6-1.fc9
	$> umask 0122
	$> stap -e 'probe begin { println("foo") exit() }'
	ERROR: Error opening '/tmp/stapV4pBIb/stap_725b9bc541cef2618a5ccbc58bb64d15_287.ko': Permission denied
	
	Obvious solution is to briefly set the umask to zero
	in stap so as to ensure 0700 permissions.
	
	Signed-off-by: Mark McLoughlin <markmc@redhat.com>

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/main.cxx.diff?cvsroot=systemtap&r1=1.82&r2=1.83