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>