From owner-cvs-all Tue Oct 20 19:46:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA06086 for cvs-all-outgoing; Tue, 20 Oct 1998 19:46:09 -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 TAA06075; Tue, 20 Oct 1998 19:46:03 -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 KAA14596; Wed, 21 Oct 1998 10:45:26 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199810210245.KAA14596@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 "Wed, 21 Oct 1998 02:28:35 +1000." <199810201628.CAA15294@godzilla.zeta.org.au> Date: Wed, 21 Oct 1998 10:45:25 +0800 From: Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Bruce Evans wrote: > >> Yes, any change breaks: > >> > >> /* > >> * Prevent even ourself from easily accessing the tmp file except > >> * via the fd returned by mkstemp(). Dont ask why :-). > >> */ > >> umask(0777); > >> fd = mkstemp(foo); > > > >man mkstemp: > > The mkstemp() function makes the same replacement to the template and > > creates the template file, mode 0600, returning a file descriptor opene d > > ^^^^ > > for reading and writing. This avoids the race between testing for a > > file's existence and opening it for use. > > man creat. It's not clear that creation has its English meaning or the > technical one of creat. I trust the code more than the man page. What does this have to do with creat()? The documentation is the definition for the interface in this case and here's specific: the file will be created mode 0600. There is no ambiguity. > >A specfic mode is specified, your example is broken, especially on NFS. > >The way to implement what you want is: > > > > fd = mkstemp(foo); > > unlink(foo); > > This has a race between the mkstemp() and the unlink(). So? It's no different to another process doing a chmod on the mode 000 file to get access to it. If you want to stop signals from making you touch the file behind your back, then do what tmpfile() does, ie: mask all maskable signals. Or just use tmpfile() and fileno() and be done with it. > >or, if you want a FILE * in the end, use "fp = tmpfile();" > > Hmm. POSIX specifies that tmpfile() shall allocate the fd as fopen() > does (and that fopen() shall allocate it as open() does). This seems > to require honouring the umask. It's irrelevant, the filesystem permissions do not "exist" because there is no file present at the return of tmpfile(). > >Yes, you are right, nvi is going gaga. However, mkstemp() is still > >broken, it does not behave as specified. This interface is not one we > >"own" and we cannot change it. > > Who owns it? The Linux (Redhat version mumble) man page says that > mkstemp() conforms to BSD 4.3 and creates the file with permissions > 0666. glibc-2.0.5c uses the same O_EXCL open as us except for using > this insecure mode. This falls squarely into the '1 million flies can't be wrong' department. Doing it that way just makes it an already dangerous operation more dangerous. > Bruce Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message