Afficher un message
Vieux 21/01/2008, 16h29   #8
Greg Herlihy
Aucun Avatar
 
Messages: n/a
Hébergeur:
Par défaut Re: tmpnam behaviour on subsequent calls

On Jan 21, 1:35am, James Kanze <james.ka...@gmail.com> wrote:
> On Jan 21, 8:39 am, Lars Uffmann <a...@nurfuerspam.de> wrote:
>
> > Jensen Somers wrote:
> > > I only have experience using this function in C, where I had
> > > to move to tempnam() because tmpnam() was causing
> > > portability issues towards Windows Vista (LUA related
> > > stuff). Although, nowadays I noticed GCC returns a warning
> > > message saying that the use of mkstemp() is advised.

> > Thank you - tempnam() suits my purpose much better. If
> > mkstemp() is advised, that is understandable in general
> > (according to documentation), but is there any way to use
> > ofstream with the integer file descriptor returned by mkstemp?
> > Doesn't seem like it to me :/

>
> In general, for security reasons, I'd avoid mkstemp, or any
> other function which opens the file for you.


The fact that mkstemp() creates and opens the file atomically is
precisely what avoids the race condition inherent in first calling
tempnam() to select the file name and then calling another function to
create a file with that name.

<Generally, you'd
> use the return value of tempnam() (which isn't C/C++) or
> tmpnam() (which is standard C/C++, but doesn't allow putting the
> temporaries in a user specified directory) to create a directory
> with restricted access rights (which again requires platform
> specific code), and place your temporary files there.


The problem of course is finding such a writable directory - and then
ensuring that its contents are deleted before the program exists - in
short, having to deal exactly the kinds of problems that calling
mkstemp() would already solve.

Greg

  Réponse avec citation
 
Page generated in 0,05009 seconds with 9 queries