Environment handling broken in /bin/sh with changes to {get,set,put}env()

[Sean C. Farley]

On Sun, 8 Jul 2007, Andrey Chernov wrote:

> On Sun, Jul 08, 2007 at 06:09:40AM +0400, Andrey Chernov wrote:
>> On Sat, Jul 07, 2007 at 09:03:59PM -0500, Sean C. Farley wrote:
>>>
>>> Surprisingly, keeping the pointers saved time even if calling
>>> setenv().
>>
>> Ok. It feels like time to commit comes :)
>
> Hmm. I just think a bit more and feel worry about that place in the
> merge code:
>
> 	*equals = '\0';
>        if (setenv(*env, equals + 1, 1) == -1)
>                return (-1);
>        *equals = '=';
> because it modifies memory which may be treated like const one.
>
> Consider following scenario: getenv() is not thread-safe, but may be
> called by thread-safe app if it is sure no other *env() calls in
> progress.  In the same time another thread of this app use environ
> directly say for exec(), assuming it is const. In the middle of that
> getenv() modifies environ by *equals = '\0';

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.

> 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.

Sean
   1. http://www.opengroup.org/onlinepubs/000095399/functions/exec.html
-- 
scf at FreeBSD.org