From owner-svn-src-all@FreeBSD.ORG Sun Oct 31 18:19:13 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 341D2106566B; Sun, 31 Oct 2010 18:19:13 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 118A98FC12; Sun, 31 Oct 2010 18:19:12 +0000 (UTC) Received: from [10.123.2.178] (DIR-655 [192.168.1.65]) by monday.kientzle.com (8.14.3/8.14.3) with ESMTP id o9VHmhX5030159; Sun, 31 Oct 2010 17:48:43 GMT (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20101031160603.GD2160@garage.freebsd.pl> Date: Sun, 31 Oct 2010 10:48:45 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <201010310921.o9V9LSo4075408@svn.freebsd.org> <20101031160603.GD2160@garage.freebsd.pl> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1081) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Ulrich Spoerlein Subject: Re: svn commit: r214596 - head/bin/rm 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: Sun, 31 Oct 2010 18:19:13 -0000 On Oct 31, 2010, at 9:06 AM, Pawel Jakub Dawidek wrote: > On Sun, Oct 31, 2010 at 09:21:28AM +0000, Ulrich Spoerlein wrote: >> Author: uqs >> Date: Sun Oct 31 09:21:27 2010 >> New Revision: 214596 >> URL: http://svn.freebsd.org/changeset/base/214596 >> >> Log: >> Elaborate some more on the non-security implications of using -P > [...] >> +.Pp >> +N.B.: The >> +.Fl P >> +flag is not considered a security feature >> +.Pq see Sx BUGS . > > I'm sorry for jumping so late into the subject, but if it is not a > security feature than what other purpose has left? > > Really guys, this option is useless. I completely agree. > There is no reliable way to verify if the blocks are really overwritten. > Period. Not from userspace, no. I think the only reasonable approach is to add a new syscall (unlink_with_overwrite(2)?) and chase the implications down through the filesystem, GEOM, and driver interfaces. Tim