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