From owner-freebsd-current@FreeBSD.ORG Fri Dec 4 16:10:35 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1373106566B for ; Fri, 4 Dec 2009 16:10:35 +0000 (UTC) (envelope-from jilles@crab.stack.nl) Received: from crab.stack.nl (crab.stack.nl [131.155.140.134]) by mx1.freebsd.org (Postfix) with ESMTP id 747DB8FC13 for ; Fri, 4 Dec 2009 16:10:35 +0000 (UTC) Received: by crab.stack.nl (Postfix, from userid 1677) id CB0675C43; Fri, 4 Dec 2009 17:10:31 +0100 (CET) Date: Fri, 4 Dec 2009 17:10:31 +0100 From: Jilles Tjoelker To: "Sean C. Farley" Message-ID: <20091204161031.GA37372@stack.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: environ function patch for review X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 16:10:35 -0000 On Thu, Dec 03, 2009 at 06:04:47PM -0600, Sean C. Farley wrote: > Regarding the recent security issue with the unsetenv() calls in rtld, I > have made a patch[1] I would like reviewed prior to commit. It changes > the behavior of all the *env() routines that cause an internal > environment to be created. This is putenv(), setenv() and unsetenv(). > getenv() will not cause an internal environment to be created. I have > tested the patch without the rltd fix, and it prevents the security > issue. > Instead of returning an error when tripping upon a corrupt environment, > it will return an error when the caller passes bad argument(s) (EINVAL) > or if unable to allocate memory (ENOMEM). Except for the possibility > for ENOMEM, this should make the behavior the same as FreeBSD 6 and > below. It would be very nice to avoid ENOMEM on unsetenv() somehow, such as by rewriting environ in place. Neither FreeBSD6 nor POSIX mention the possibility of ENOMEM on unsetenv(). The only error listed by POSIX is an invalid variable name (unsetting a variable that does not exist is not an error), so it seems reasonable to assume unsetenv() is successful if passed a valid constant variable name. If unsetenv() has to copy the environment, there cannot be any setenv() or putenv() strings in it. So it seems correct to remove the pointer from environ without doing anything else, instead. If the environment has already been copied, the unsetenv() should proceed without needing to allocate any memory. This seems to be the case. -- Jilles Tjoelker