Bug 4350 - Reentrancy problem between strftime() and setenv()
Summary: Reentrancy problem between strftime() and setenv()
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
Depends on:
Reported: 2007-04-12 14:42 UTC by Petr Baudis
Modified: 2014-07-14 09:24 UTC (History)
1 user (show)

See Also:
Last reconfirmed:
fweimer: security-

Proposed patch (1.19 KB, patch)
2007-04-12 14:43 UTC, Petr Baudis
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Baudis 2007-04-12 14:42:39 UTC
Threaded programs may crash randomly if strftime() and setenv() aren't excluded
from being called in parallel, since getenv() is called from the inside of
strftime(). While getenv()-setenv() thread safety problems are documented, it is
not documented that time functions have these problems as well. The proposed
patch introduces getenv_r() as a reentrant version of getenv() and uses it from
inside of the time functions; maybe you'll choose a different approach (or a
different name for the function or so), but something should be done about this.
Also, maybe other parts of glibc making use of getenv() might need the same fix.
Comment 1 Petr Baudis 2007-04-12 14:43:08 UTC
Created attachment 1676 [details]
Proposed patch
Comment 2 Petr Baudis 2007-04-12 14:45:20 UTC
(Forgot to mention that the patch was written only partially by me, a large part
came from a customer of Novell.)
Comment 3 Jakub Jelinek 2007-04-13 18:50:42 UTC
strftime is documented in POSIX that it acts as if it calls tzset().
And tzset is documented to inspect the TZ env variable.
setenv is documented to be non-thread safe, what glibc does there is beyond
what the standard requires.  And this is IMHO the same thing.
Comment 4 Petr Baudis 2007-04-26 18:11:39 UTC
Strictly speaking, it doesn't say that it inspects $TZ in a non-reentrant way
(using getenv()), does it? But I agree that this is quite a nitpicking. But
still, what are the considerations against integrating such a patch? Just the
possible small performance penalty?
Comment 5 Ulrich Drepper 2007-05-08 04:20:03 UTC
The environment cannot be made thread-safe.  It's ridiculous that programs even
use setenv() for purposes other then calling exec afterwards.  There is no
reason to jump through hoops and punish every program out there just because
some people cannot program.