svn commit: r199983 - in head: lib/libc/stdlib
M. Warner Losh
imp at bsdimp.com
Wed Dec 2 02:42:37 UTC 2009
In message: <alpine.BSF.2.00.0912011514510.84941 at fledge.watson.org>
Robert Watson <rwatson at 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.
More information about the svn-src-head