Re: [PATCH] misc: Add mkostempat (BZ 19866)

* Mark Wielaard:

> Hi Florian,
>
> On Fri, Jun 26, 2026 at 10:00:12AM +0200, Florian Weimer wrote:
>> * Florian Weimer:
>> > * Paul Eggert:
>> >> In the end it's simpler to have a function with a callback.
>> >
>> > Splitting probing and name creation has the same problem as tmpnam:
>> > creation might not use O_EXCL (either explicitly or implicitly).  It
>> > seems to me that a callback-based interface mostly serves to obfuscate
>> > the relationship to the deprecated tmpnam function.
>> >
>> > We can acknowledge that deprecating tmpnam was a mistake and introduce a
>> > tmpnamat function.  Not splitting probing and creation introduces a
>> > proliferation of interfaces.  I think this would be cleaner than the
>> > callback-based approach, and easier to consume from languages such as
>> > Python.
>> 
>> To expand on that a little: the problem with tmpnam is not just the
>> possibility of a TOCTOU race if used incorrectly.  The risk is amplified
>> by the relatively short uniqueness string (six characters, so 35.7 bits
>> of entropy at most) and, historically, a lack of a good entropy source.
>> For tmpnamat, we can recommend a uniqueness string of at least 10
>> characters (59.5 bits), which will make a TOCTOU race impractical to
>> exploit.  We can document which function combinations are safe to use.
>
> Could you expand a bit more? I am not exactly sure I understand what
> you are proposing. Are you proposing we switch to a tmpname[at] style
> funcion that just provides a unique name and that the user combines
> this with their own creation function for whatever they want in given
> directory? Would they then use this in some kind of loop till an
> O_EXCL using function succeeds?

Yes, that would be the approach.  We might not even need to check that
the path does not exist before returning it because we expect the caller
to do that (preferably through an O_EXCL-type mechanism).

> Or would there be some kind of guarantee that the result of
> tmpname[at] would be statistically random enough that any toctou race
> would be impossible (or if it would happen it really just counts as a
> failure to create any temp file)?

I think it's both.  More random bits mean that failure to use O_EXCL
correctly is not necessarily exploitable in practice.  I think it's
better to have a simple (not callback-based) interface that can be
composed with *at functions, rather than have special-case functions
that provide random name creation for various *at variants.  Something
callback-based is also not desirable because it's hard to use correctly
from FFI.

If we don't check for the existence of the path, the function will
simply compute a string from various inputs.  It doesn't even need the
directory descriptor.

There might still be a missing building block because there isn't any
TMPDIR handling, but that's a preexisting issue even in mkostemp.

Thanks,
Florian