From owner-svn-src-all@FreeBSD.ORG Sat Apr 3 11:53:58 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 274381065674 for ; Sat, 3 Apr 2010 11:53:58 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id C4A328FC1E for ; Sat, 3 Apr 2010 11:53:57 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so946995qwe.7 for ; Sat, 03 Apr 2010 04:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qzx8WZjyhXFPOG+qP/JhGn63qE9/cWor32rV7vAEwME=; b=f7slFcPIj59EnvW+tGe0vCIKpR4bRU16dD3xyFiyAhqbJ1lALNmD+kSoEaEsrUWRsG AT6x0UpUD8Ns/lsCvPWbDfJIiD2b1xpR4tGFpCqO/8zh60tIhNqMeVKDdtwgmbQMJXeM T2mDi0gHso012WycIsmozmyRFoBZutD73SVCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xM/xHD5ejeBBA50lsaheLkzL6uUNDrfMhcH3/+AyDZ3IrSX9pkihwj5UKO/4HW/L1H 4lhl8mUuRvcm2sTSEjCEYQGte9YSknwofbzIfKZg3EcJ4DnrxFv9nymnjHfnNks14rra kshXmephd8gbSuDJKp7HDzZzrlZ4N+ZO49U24= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Sat, 3 Apr 2010 04:53:51 -0700 (PDT) In-Reply-To: <20100403114055.GC23007@britannica.bec.de> References: <201004011427.o31ERTaT056824@svn.freebsd.org> <20100402001231.GA16732@britannica.bec.de> <20100403114055.GC23007@britannica.bec.de> Date: Sat, 3 Apr 2010 04:53:51 -0700 Received: by 10.229.224.133 with SMTP id io5mr5470068qcb.37.1270295632106; Sat, 03 Apr 2010 04:53:52 -0700 (PDT) Message-ID: From: Garrett Cooper To: Joerg Sonnenberger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-all@freebsd.org Subject: Re: svn commit: r206043 - in head/usr.sbin/pkg_install: add delete lib version X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 11:53:58 -0000 On Sat, Apr 3, 2010 at 4:40 AM, Joerg Sonnenberger wrote: > On Sat, Apr 03, 2010 at 04:32:15AM -0700, Garrett Cooper wrote: >> =A0 =A0I'm sorry but I'm a little bit confused by this statement: do you >> mean that you're replacing PATH_MAX sized buffers to FILENAME_MAX >> sized buffers? If so this may cause an issue because several of the >> variables used in constructing the file paths in pkg_install aren't >> necessarily correct in overflow cases. We need to avoid introducing >> potential functional flaws with filename truncation like this. > > No, I am replacing fixed size buffers with variable size buffers. The > extraction code should generally be able to support arbitrary deep path > names, for the rest the kernel can complain. Depending on how this is implemented, this could either be a minor functional issue, or a really bad security issue then waiting to happen because people can craft paths such that things aren't properly are either incorrect in the best case scenario, or could provide a back door to circumvent some points in how packages are installed, etc. Furthermore dynamic heap allocation and deallocation turns into a pain with pkg_install (for instance in its current incarnation on FreeBSD) because there are a number of exit points in the system that need to be covered in order to do things correctly and properly. sysinstall and pkg_install [in FreeBSD] are enough of a mess without introducing new potential functional and security flaws, and unnecessary complexity. I'd rather not do down this road especially when we know the limitations of the operating systems' filesystems via well-defined and well-known constants, and when these buffers are small enough and spread far enough in-between that it shouldn't necessarily be a scalability issue. Thanks, -Garrett