Pedro Margate wrote:

> Greetings,
>
> There was recently a fairly long and involved thread on BUGTRAQ or
> VULN-DEV discussing temp files. I believe the general consensus is as
> follows:
>
> 1. Keeping temp files in world-writable /tmp is a Bad Thing (tm). It's
> better to keep them in a directory where only authorized users can read
> them. Using group permissions, it should be possible to place temp files
> somewhere, even in a subdirectory of /tmp, if you like, where not everyone
> in the whole world can fiddle with it.

This is being coded with the idea that anyone who has access to the
system will be able to run this program. Putting group permissions on
the file still means anyone in that group can act maliciously.

> 2. Keeping world-writable files in /tmp is an Even Worse Thing (tm). This
> practice opens you up to malicious users filling your /tmp disk and, if
> you use tmpfs, your swap space.

/tmp is already world writable. Any user can fill it up at will.

> 3. If you must put temp files in /tmp, don't use a predictable filename,
> such as a constant, $$, $$^$$, or any of the other classics. Use a
> library function such as mkstemp to create a unique file that doesn't
> already exist.

It needs to be perdictable so all the processes no which file to use.

> With respect to your code, the only problem I can see (aside from the
> tmpfile handling) is that it might not do what you want it to do, since I
> don't see the filehandle $_dbstatfh being closed anywhere, and the mtime
> on the file is only updated when the file is closed or flushed. Of

> course, if you did a "select $_dbstatfh; $| = 1;" (enable autoflush)
> prior to calling this function, that would take care of that problem.

In perl 5.005 and up, when you do flock FH, LOCK_UN the file is
automatically flushed. So that part is taken care of.

Thanks,
Paul Baker

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]