Date: Tue, 16 May 2000 11:46:25 -0600 From: Wes Peters <wes@softweyr.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Kris Kennaway <kris@FreeBSD.ORG>, Tim Vanderhoek <vanderh@ecf.utoronto.ca>, James Howard <howardjp@wam.umd.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: mktemp() vs. mkstemp() Message-ID: <39218971.AE6779B5@softweyr.com> References: <Pine.BSF.4.21.0005141952440.20005-100000@freefall.freebsd.org> <39204472.706CB1D2@softweyr.com> <20000515123256.C249@fw.wintelcom.net>
index | next in thread | previous in thread | raw e-mail
Alfred Perlstein wrote:
>
> * Wes Peters <wes@softweyr.com> [000515 12:11] wrote:
> > Kris Kennaway wrote:
> > >
> > > On Sun, 14 May 2000, Tim Vanderhoek wrote:
> > >
> > > > It's certainly not like it would be the first non-portable function
> > > > we've added. Where adding functions to libraries encourages better
> > > > coding practices, I'm (often) in favour of it, especially if it
> > > > encourages more secure coding practices. Ultimately everyone
> > > > benefits, and the pain is short-term.
> > >
> > > True, but I'd venture that in most of those cases they did something a
> > > little less trivial than one line of code.
> >
> > We could simply redefine mktemp to not be such a security hole. Do
> > common programs that use mktemp depend on side effects?
>
> The side effect they depend on is that the char * returned is unique,
> but since no file was created it's not garanteed so. You can't fix
> it.
Drat, that's right. Anyone wanna pollute the kernel and filesystem
layers with a "reserve this filename" function? That sounds fugly,
doesn't it?
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
wes@softweyr.com http://softweyr.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39218971.AE6779B5>