[MINC-development] patches for tmpnam

[Robert VINCENT]

On Thu, 6 Mar 2003, Peter NEELIN wrote:

> BTW, does anyone know to what extent this is a security risk? My guess
> would be that this is only a risk for either root (or setuid
> root) applications. Have I missed something?
>
> [Comments about over-zealous gcc/glibc developers suppressed...]
>

I think the risk is minor; this isn't like calling gets() on a network
socket.

So, with thanks to Vicka for pushing the issue, I've made and tested some
changes I'd like to propose.  In a nutshell, I created a new global minc
function named "micreate_tempfile()".  I chose this name because I wanted
it to reflect the fact that the function actually creates the file, but
closes it before returning.  The function is obsessively #ifdef'd to deal
with systems that define neither mkstemp() nor tempnam(), but hopefully
this is just overkill.  If I did things right, the function should leak
neither memory nor file descriptors.

Here's a summary of the files that changed:

In configure.in
- Added AC_CHECK_FUNCS(mkstemp tempnam tmpnam)

In libsrc/netcdf_convenience.c
- Added definition of "int micreate_tempfile(char *name_ptr, int name_len)"
- Replaced call to tempnam() with call to micreate_tempfile()
- Added #include "config.h"
- Added #include <sys/stat.h>

In libsrc/minc.h
- Added declaration of micreate_tempfile(), and MI_MAX_PATH

In volume_io/Prog_utils/files.c
- Replaced 2 calls to tmpnam() with calls to micreate_tempfile()

In volume_io/Volumes/volume_cache.c
- Replaced 1 call to tmpnam() with micreate_tempfile()

The entire MINC 1.1 source now builds on Linux 7.3 and GCC 2.96 with nary
a peep from the linker.  Does anyone want to review these changes in
detail before I commit them?  Is there a preferred way to distribute the
changes for review, or do folks just want to examine them in
~bert/projects/minc/cvsroot/minc (which should be world-readable).

	-bert