[MINC-development] patches for tmpnam

[Peter NEELIN]

On Mon, 10 Mar 2003, Steve ROBBINS wrote:

> On Mon, Mar 10, 2003 at 10:34:19AM -0500, Robert VINCENT wrote:
> >
> > I thought that having the function create the file avoids the worst
> > aspects of the race condition, since the file is known to have been
> > created successfully with relatively secure permissions and ownership.
>
> No, that buys you nothing.  Once you close the file, all bets are
> off.

I'm not sure that this is correct. mkstemp creates the file and returns a
file descriptor. The file is NOT unlinked, so closing it leaves it in
place with the correct ownership and permissions. Under irix, with
the sticky bit set on the /var/tmp directory (as is done at the BIC),
other users cannot do malicious things to the file. A subsequent open
(from gzip, for example) will truncate the file (if the correct open flags
are used) without leaving the race condition open. "man 2 stat" suggests
that the same is true under linux. Of course, it is up to the sysadmin to
ensure that the permissions are correctly set on the tmp directories, but
my Mandrake system does have the sticky bit set on /tmp and /var/tmp, so
I'm guessing that most linux distros do it correctly. (I know, that is a
bit of an extrapolation!)

Please correct me if I am wrong, Steve - I just don't see the hole.

> More precisely, the file did exist at one time with owner read/write
> permissions.  Once you close it, the file is gone.  Anything can happen
> during the interval that you close and re-open the file.

Nope. You're thinking of tmpfile. It unlinks after opening the file. It
does not return a file name because using the file name would still suffer
from the face condition (the file that once existed with the name still
exists, but no longer has a name).

> In addition, it's nicer on client programmers when a library uses
> a consistent policy with regards to this issue.  Volume_io already
> has get_temporary_filename() which returns allocated memory so why
> not just promote this function's semantics into MINC proper?

'Sounds like a good plan.

            Peter
----
            Peter Neelin (neelin@bic.mni.mcgill.ca)