Date: Tue, 20 Oct 1998 22:29:11 +0800 From: Peter Wemm <peter@netplex.com.au> To: Bruce Evans <bde@zeta.org.au> Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdio mktemp.c Message-ID: <199810201429.WAA11949@spinner.netplex.com.au> In-Reply-To: Your message of "Tue, 20 Oct 1998 23:24:01 %2B1000." <199810201324.XAA03509@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199810201429.WAA11949>