Date: Sun, 8 Jul 2007 13:14:31 -0500 (CDT)
From: "Sean C. Farley" <scf@FreeBSD.org>
To: Andrey Chernov <ache@nagual.pp.ru>
Cc: freebsd-current <freebsd-current@FreeBSD.org>, Robert Watson <rwatson@FreeBSD.org>, Michal Mertl <mime@traveller.cz>
Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env()
Message-ID: <20070708125905.F14065@thor.farley.org>
In-Reply-To: <20070708171727.GA90490@nagual.pp.ru>
References: <20070704235630.GA42227@nagual.pp.ru> <20070704215154.O77978@thor.farley.org> <20070705115816.GA50506@nagual.pp.ru> <20070705105922.F98700@thor.farley.org> <20070707130859.GA96605@nagual.pp.ru> <20070707131359.GB96605@nagual.pp.ru> <20070707133102.C14065@thor.farley.org> <20070707191835.GA4368@nagual.pp.ru> <20070707205410.B14065@thor.farley.org> <20070708020940.GA80166@nagual.pp.ru> <20070708171727.GA90490@nagual.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070708125905.F14065>