From owner-cvs-all Tue Oct 20 07:30:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA20822 for cvs-all-outgoing; Tue, 20 Oct 1998 07:30:11 -0700 (PDT) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA20817; Tue, 20 Oct 1998 07:30:06 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Spinner) with ESMTP id WAA11949; Tue, 20 Oct 1998 22:29:11 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199810201429.WAA11949@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Bruce Evans cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdio mktemp.c In-reply-to: Your message of "Tue, 20 Oct 1998 23:24:01 +1000." <199810201324.XAA03509@godzilla.zeta.org.au> Date: Tue, 20 Oct 1998 22:29:11 +0800 From: Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Bruce Evans wrote: > > Modified files: > > lib/libc/stdio mktemp.c > > Log: > > Stop mk*temp() from being pathologically stupid in the face of a umask(0); > 077 7 > > There are other ways to fix this than wrapping _gettemp(), but this was > > the most convenient. > > Erm, why shouldn't it honour the umask? stdio still honours the umask in > all other places. For fopen(), this is actually documented in fopen.3, > and is sort of specified by POSIX.1 for fopen(): "the fopen() function > shall allocate a file descriptor as open() does". > > Bruce I'm not sure how to best fix it that is *safe*. Leaving it failing due to the umask preventing it from opening the file it just created isn't ideal because the mk*temp() function has *failed* and yet it still created the file. I don't believe it's safe to unconditionally attempt to unlink() the file when the open(..O_CREAT|O_EXCL) returns EPERM. Making it respect the umask achieves nothing except making error recovery difficult or complicated. I don't like the idea of open with 0666 modes because that creates potential vulnerabilities. It is better to start with a restricted set of permissions and then expand them if needed. One might be working in a chmod 700 directory somewhere, only to have something like gcc or vi open a file in /tmp with a copy of your work being globally readable in /tmp. mkstemp() is explicitly defined as returning a 0600 file, and mkdtemp() are explicitly defined as creating 0700 directories. I don't recall seeing anywhere in our sources that actually have to open up restrictions returned from mk*temp(). Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message