Date: Wed, 4 Jul 2007 12:53:25 -0500 (CDT)
From: "Sean C. Farley" <scf@FreeBSD.org>
To: Robert Watson <rwatson@FreeBSD.org>
Cc: Andrey Chernov <ache@nagual.pp.ru>, freebsd-current <freebsd-current@FreeBSD.org>, Michal Mertl <mime@traveller.cz>
Subject: Re: Environment handling broken in /bin/sh with changes to {get,set,put}env()
Message-ID: <20070704121316.A77978@thor.farley.org>
In-Reply-To: <20070704173905.T67251@fledge.watson.org>
References: <1183557221.1799.16.camel@genius.i.cz> <20070704143642.GA31254@nagual.pp.ru> <20070704150312.GB31683@nagual.pp.ru> <20070704101026.O77978@thor.farley.org> <20070704173905.T67251@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Jul 2007, Robert Watson wrote: > On Wed, 4 Jul 2007, Sean C. Farley wrote: > >> On Wed, 4 Jul 2007, Andrey Chernov wrote: >> >>> On Wed, Jul 04, 2007 at 06:36:42PM +0400, Andrey Chernov wrote: >>>> 2) "s" may point to getenv()-provided value there. So just >>>> modifying it directly followed by setenv() call will make things >>>> inconsistent. >>>> >>>> 3) In my version of patch there was savestr() which copy arg to >>>> avoid this situation. >>>> >>>> Fix will be to restore var.c to mine variant 1.34 >>> >>> You may also try this patch against var.c 1.36: >> >> Andrey, thank you. >> >> Sorry for the bug everyone. Here is a patch that should fix it: >> http://www.farley.org/freebsd/tmp/setenv/sh.patch > > I assume I'm not the only person with this concern, but -- shouldn't > we worry that subtle changes in the semantics of very basic and widely > used system APIs might not result in more of exactly this sort of > problem? While I'm supportive of the general aim of improving the > portability of our APIs, environmental variables are managed by large > numbers of programs in rather subtle ways--do we generally feel that > this recent work will decrease or increase the number of subtle bugs? > After all, we've changed long-standing semantics for the APIs... I admit the bugs are showing up due to the *env() change, yet the bugs are actually due to the improper use of environ and the *env() functions rather than the code in getenv.c. For example, sh was taking pointers directly from environ and passing them back into *env() functions. I am not certain that sh would work even with OpenSolaris since it does similar things to environ under the covers. My concern is that many portable programs assume all UNIX systems comply with the POSIX specification in regards to *env() functions. Of course, they should check the man page for differences, but that does not always happen. It took several times before I learned that lesson. :) I am also actively looking for other potential bugs from this type of misuse. /bin/sh did not show up for me since I did not have LANG (or any other locale variable sh cares about) set in my environment. Sean -- scf@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070704121316.A77978>