From owner-cvs-all@FreeBSD.ORG Sun Jan 27 07:55:02 2008 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D98216A41A; Sun, 27 Jan 2008 07:55:02 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD7C13C478; Sun, 27 Jan 2008 07:55:01 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.12.9/8.12.9) id m0R7t1ZM084081; Sat, 26 Jan 2008 23:55:01 -0800 (PST) (envelope-from kientzle@freebsd.org) Received: from [10.0.0.209] (p54.kientzle.com [66.166.149.54]) by kientzle.com with SMTP; Sat, 26 Jan 2008 23:55:01 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <479C38D5.3050901@freebsd.org> Date: Sat, 26 Jan 2008 23:55:01 -0800 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060422 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yar Tikhiy References: <200801261709.m0QH9f2D024309@repoman.freebsd.org> In-Reply-To: <200801261709.m0QH9f2D024309@repoman.freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src UPDATING src/include fts.h src/lib/libc/gen Makefile.inc Symbol.map fts-compat.c fts-compat.h fts.3 fts.c src/sys/sys param.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2008 07:55:02 -0000 Yar Tikhiy wrote: > Our fts(3) API, as inherited from 4.4BSD, suffers from integer > fields in FTS and FTSENT structs being too narrow. In addition, > the narrow types creep from there into fts.c. As a result, fts(3) > consumers, e.g., find(1) or rm(1), can't handle file trees an ordinary > user can create, which can have security implications. Kudos! It's about time we fixed this. The inability of 'rm' to clean up my test trees for libarchive has become a bit tiresome. ;-) Tim Kientzle