Re: "dangerous" warning question

[Brian Dessent <brian at dessent dot net>]

NightStrike wrote:

> Would the best course of action be to remove calls to choose_temp_base
> from those aforementioned files, and to further change the way
> choose_temp_base works to call mkstemp instead of mktemp?  Or would
> that break other things?

No, the problem is that both choose_temp_base and mktemp represent the
same broken semantics, namely "give me the name of a unique temporary
file that does not exist but do not open it yet."  mkstemp is not a drop
in replacement for mktemp because it solves the race condition by doing
the uniqueness check and the opening of the file as an atomic step, and
returns the integer fd of this newly opened file.

You could implement choose_temp_base in terms of mkstemp but that would
be kind of silly in that the temporary file would be created, opened,
and closed, only to later be opened again by the caller.  And there
would still be a possibility of a race condition, although it would
probably be much harder to exploit.

And in fact the above already exists in libiberty as make_temp_file, so
it looks like the best short term solution would be to replace users of
choose_temp_base with that.  (Although there is also make_tempname in
bucomm.c that might be usable but this has the strange logic that if the
target doesn't have mkstemp it falls back to mktemp instead of using the
mkstemps replacement that's in libiberty...)

> I'm obviously a fledgling in this regard -- just trying to learn, so I
> appreciate your patience and your verbosity.  The indepth answers that
> you, and everyone on this list, provides is immensely helpful.

And I was wrong about how the glibc warning works.  Since it's
implemented as a link-time thing you should only get the warning if
there is a call to mktemp in the final link, meaning that if all callers
to choose_temp_base are cleaned up it shouldn't matter that there is
still a call to mktemp in libiberty.a as that's dead code.

Brian