[PATCH] misc: Add mkostempat (BZ 19866)
Mark Wielaard
mark@klomp.org
Thu Jun 25 21:59:52 GMT 2026
Hi,
On Wed, Jun 24, 2026 at 08:41:04AM -0300, Adhemerval Zanella Netto wrote:
> On 24/06/26 07:11, Mark Wielaard wrote:
> > For me the most important thing is having a simple function to create
> > a temporary file in a specific directory, so you can get rid of any
> > path based calls (which are a toctou footgun). So I don't like an
> > interface where the dirfd argument needs to be passed around through a
> > callback closure and I need to select or write a specific
> > callback. All the other arguments however are fine to hide that way
> > because all I really need is giving a n dirfd and getting an file
> > descriptor and name back. I don't care about the name really, and
> > would trust glibc to pick the right amount of randomness, mode and
> > flags.
> >
> > But if you don't believe the path based way of invoking the mk*stemp*
> > functions is the biggest footgun then the name/template becomes more
> > important as argument not to get wrong.
> >
> > I am wondering if we should have both a super generic mkostempfn and a
> > specific mkostempat function (implemented on top of the mkostemfn).
>
> Just to be clear, I do prefer the original one:
>
> int mkostempat (int dirfd, /* as other *at functions. */
> const char *prefix, /* maybe a relative or absolute. */
> const char *suffix, /* no '/' allowed; may be "" */
> unsigned int n_random, /* entropy chars, 0 -> default 6 */
> int oflags, /* extra O_* OR'd into the create */
> mode_t mode, /* e.g. 0600 */
> char *namebuf, /* output, or NULL */
> size_t namebuf_size); /* bound; ERANGE/ENAMETOOLONG on overflow */
>
> Where namebuf_size can be inferred by strlen(prefix)+strlen(suffix)+n_random.
I could live with that. Not a fan of the namebuf/size thing though,
just because I would immediately be confused whether that includes the
terminating zero or not. But OK.
> As I said, it fixes a lot of footguns from the mkstemp* functions, without
> re-introducing more or adding error-prone interfaces like typeless callback
> (yes, we are coding in C but we can also do better and avoid repeating historic
> mistakes).
>
> I am exploring this callback interface more to check what kind of shortcomings
> we might have; and I am not sure the gnulib example interfaces are really
> a fit for glibc.
The example that Paul gave was being able to call something else
instead of openat. You could call openat2 or symlinkat for
example. Which are certainly nice features. But also maybe not
directly what someone might expect from a mkstemp function.
> In fact, after this discussion I am not even sure if glibc is indeed the
> correct place for a new mkstem* function. Any pick choice in this discussions
> will have some shortcoming.
If not, can we have a simple mkstempat one that just adds the dirfd
argument, but doesn't try to fix any other issue?
Thanks,
Mark
More information about the Libc-alpha
mailing list