From owner-cvs-all  Tue Oct 20 08:00:13 1998
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id IAA23236
          for cvs-all-outgoing; Tue, 20 Oct 1998 08:00:13 -0700 (PDT)
          (envelope-from owner-cvs-all@FreeBSD.ORG)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA23224;
          Tue, 20 Oct 1998 08:00:08 -0700 (PDT)
          (envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id AAA10106;
	Wed, 21 Oct 1998 00:59:40 +1000
Date: Wed, 21 Oct 1998 00:59:40 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199810201459.AAA10106@godzilla.zeta.org.au>
To: bde@zeta.org.au, peter@netplex.com.au
Subject: Re: cvs commit: src/lib/libc/stdio mktemp.c
Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

>I'm not sure how to best fix it that is *safe*.

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);

>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

mk*temp() hasn't failed.  It returns a r/w file descriptor for a file
with mod 0000.  vi has problems when it closes this fd and attempts to
reopen it.

For mktemp() and other inferior tmp file functions, there is no way for
the library to affect the mode.

The library shouldn't change the umask except possibly in functions like
setmode() where signals are blocked.

Bruce

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message