Environment handling broken in /bin/sh with changes to
{get,set,put}env()
Andrey Chernov
ache at nagual.pp.ru
Sun Jul 8 18:38:26 UTC 2007
On Sun, Jul 08, 2007 at 01:14:31PM -0500, Sean C. Farley wrote:
> SUSv3 states that that is not a safe assumption to make. Read the
> paragraph starting with "Conforming multi-threaded" from exec(3)[1]. It
> basically equates direct use of the environ variable as the same as any
> *env() call.
>From my reading, not exactly so:
"Conforming multi-threaded applications shall not use the environ variable
to access or modify any environment variable while any other thread is
concurrently modifying any environment variable. A call to any function
dependent on any environment variable shall be considered a use of the
environ variable to access that environment variable."
They say "while any other thread is concurrently _modifying_ any
environment variable" but getenv() is not supposed to modify environ in
any way. They cleary separate "access" and "modify" terms in this
paragraph.
>From getenv():
"The getenv() function shall _search_ the environment of the calling
process"
I.e. no "modify" word found in getenv() description (and whole manpage).
Meanwhile, they say in getenv():
"If the application modifies environ or the pointers to which it points,
the behavior of getenv() is undefined."
So we are free here to do the most reasonable strategy (as undefined).
Modifying environ is "undefined" too, of course, but not looks so
reasonable.
>> Could you please make setenv() wrapper like that to avoid modifying
>> merged environ in the middle?
>> __lsetenv(str, str_len, value)
>
> I could add this as a feature later. Unfortunately, unless I can lock
> the use of environ, an application could do this even with the 6-STABLE
> version of *env() functions. I have been pondering about thread-safety
> in a future release of these functions (8-CURRENT), but it may not be
> possible since environ is exposed.
Even in case it may happens with 6-STABLE, we better not repeat the way
lead to mistakes again :)
> Sean
> 1. http://www.opengroup.org/onlinepubs/000095399/functions/exec.html
--
http://ache.pp.ru/
More information about the freebsd-current
mailing list