From owner-svn-src-head@FreeBSD.ORG Wed Dec 2 19:11:54 2009 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C6CF1065693; Wed, 2 Dec 2009 19:11:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7E58FC27; Wed, 2 Dec 2009 19:11:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id nB2J3HNJ089051; Wed, 2 Dec 2009 12:03:17 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 02 Dec 2009 12:03:36 -0700 (MST) Message-Id: <20091202.120336.-491321773.imp@bsdimp.com> To: scf@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <20091201.193518.387188323.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: green@FreeBSD.org, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, rwatson@FreeBSD.org, cperciva@FreeBSD.org, svn-src-head@FreeBSD.org Subject: Re: svn commit: r199983 - in head: lib/libc/stdlib tools/regression/environ X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2009 19:11:54 -0000 In message: "Sean C. Farley" writes: : On Tue, 1 Dec 2009, M. Warner Losh wrote: : : > In message: : > Robert Watson 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. : : Which "whole thing"? The code or the POSIX-compliance? Technically, it : is not pure compliance because the code has a few BSD requirements in it : such as keeping old name=value entries even when new ones are created. I'm calling for something fairly radical: Go back to the code that was working before and abandon all this POSIX code. If someone wants to reimplement it correctly, securely and audits the system to prove it, then it can go back in. We've had two black eyes from the current code and I have little confidence that all the subtle problems have been resolved with it. My gut tells me there are more lurking, although that can be hard to quantify into an actionable item. I don't think there's much support for this position, so the next best thing is what consensus appears to be calling for: fix the current code in a fail-safe manner. Warner