Date: Tue, 01 Dec 2009 19:35:18 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: rwatson@FreeBSD.org Cc: svn-src-head@FreeBSD.org, green@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, cperciva@FreeBSD.org Subject: Re: svn commit: r199983 - in head: lib/libc/stdlib tools/regression/environ Message-ID: <20091201.193518.387188323.imp@bsdimp.com> In-Reply-To: <alpine.BSF.2.00.0912011514510.84941@fledge.watson.org> References: <200912010504.nB154VnS053167@svn.freebsd.org> <4B14B32C.3060409@freebsd.org> <alpine.BSF.2.00.0912011514510.84941@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <alpine.BSF.2.00.0912011514510.84941@fledge.watson.org>
Robert Watson <rwatson@FreeBSD.org> writes:
: On Mon, 30 Nov 2009, Colin Percival wrote:
:
: > Brian Feldman wrote:
: >> Do not gratuitously fail *env(3) operations due to corrupt ('='-less)
: >> **environ entries. This puts non-getenv(3) operations in line with
: >> getenv(3) in that bad environ entries do not cause all operations to
: >> fail. There is still some inconsistency in that getenv(3) in the
: >> absence of any environment-modifying operation does not emit corrupt
: >> environ entry warnings.
: >>
: >> I also fixed another inconsistency in getenv(3) where updating the
: >> global environ pointer would not be reflected in the return values.
: >> It would have taken an intermediary setenv(3)/putenv(3)/unsetenv(3)
: >> in order to see the change.
: >
: > The FreeBSD Security Team is currently dealing with a security issue
: > relating to this code. Please back out your change (at least to getenv.c; I
: > don't particularly care about the regression tests) until we've finished,
: > and then submit the patch to us for review along with a detailed explanation
: > of what it does.
: >
: > We've already had two major security issues arising out of getenv.c in the
: > past year, and I'd like to make sure we don't have a third.
:
: I think it's fair to say that the POSIXization of the environment code has
: been an unmitigated disaster, and speaks to the necessity for careful review
: of those sorts of code changes.
Why we're not just reverting the whole thing as a bad idea is beyond
me. Clearly the tiny incremental benefits have been far overshadowed
by this fiasco.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091201.193518.387188323.imp>