[GRASS5] [bug #2877] (grass) Insecure tempfile creation

[Glynn Clements]

[Recipient list trimmed.]

Hamish wrote:

> > GRASS bugtracker:
> > this bug's URL: http://intevation.de/rt/webrt?serial_num=2877
>  
> > Debian Bug #287651:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=287651
>  
> Temporary files in GRASS C modules should use G_tempfile() or
> G__tempfile(), and GRASS scripts should be using the g.tempfile
> module:

However, G_tempfile() serves a dual purpose. It is used for both
normal temporary files and for internal GRASS data files (e.g. the
cell array).

[What follows is from memory; I haven't yet re-installed the GRASS
source code following a recent disk failure.]

In the latter case, G_open_cell_new() etc uses G_tempfile() to create
the actual cell file. Once the map is closed with G_close_cell(), the
new file is moved into place (possibly replacing an existing file)
using rename() or link().

In that situation, the file has to be created on the filesystem (i.e. 
partition) where it will eventually end up, i.e. the one which
contains where mapset directory resides, which is why the files are
created unde $LOCATION/.tmp.

OTOH, "normal" temporary files could reasonably be created in e.g. 
$TMPDIR (tempnam() automatically uses $TMPDIR if it is set), which
should eliminate any security issues ($TMPDIR typically resides under
$HOME, and is only writable by its owner).

That would require separate functions for the two cases. The
(relatively few) libgis functions which use G_tempfile() for the
specific reasons described above would use the function which behaves
like the existing G_tempfile(), while most other code would use the
function which uses /tmp or $TMPDIR.

Given that relatively little code relies upon the specific location of
the temporary file, the easiest solution would be to give the existing
G_tempfile() function a new name and call the new function
G_tempfile().

-- 
Glynn Clements <glynn at gclements.plus.com>