[systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)

[Lennart Poettering]

On Mon, 27.01.14 18:40, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> 
> On Mon, Jan 27, 2014 at 05:54:58PM +0100, Kay Sievers wrote:
> > On Mon, Jan 27, 2014 at 5:35 PM, Zbigniew Jędrzejewski-Szmek
> > <zbyszek at in.waw.pl> wrote:
> > > On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote:
> > >> Yupp, it's certainly a good idea to make our logging functions safe for
> > >> execution in any context.
> > >>
> > >> What I don't understands though is why mkostemp() would not be safe here?
> > > mkostemp is not on the list of "safe" functions. I looked at the
> > > implementation, and it actually has a static variable, so it really
> > > cannot be called.
> > 
> > But does this matter here? The static var is still mixed with random.
> > It seems it will work just fine, at least with the next iteration?
> I guess it's a question whether we want to rely on a specific
> implementation, or on the promises made by standards/documentation.
> mkostemp might call the random number generator, which might modify some
> global state, etc, which could be visible from outside of the signal handler.
> It just feels risky to make promises about this.

Maybe we should just implement our own version of mkostemp() for this,
which uses /dev/urandom instead of the RNG. ANd that always use that,
even in the non async-signal-safe case... This is not time-critical and
a fall-back anyway, so I don't see an issue here.

I just really don't like exposing two codepaths to the user. I want one
version that works for everybody, because people are highly like to
misuse this otherwise. Logging is so basic that people shouldn't be able
to fuck it up...

That said, I am pretty happy to just assume glibc behaviour here as sane
behaviour and ignore other implementations. It is relatively safe to
assume that the glibc guys are aware of the async-signal safety problems
and won't make this worse...

Lennart

-- 
Lennart Poettering, Red Hat