From owner-svn-src-head@FreeBSD.ORG Sun Oct 31 19:57:59 2010 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 4AAC41065673; Sun, 31 Oct 2010 19:57:59 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2001:470:9a47::1]) by mx1.freebsd.org (Postfix) with ESMTP id D4D3B8FC1A; Sun, 31 Oct 2010 19:57:58 +0000 (UTC) Received: from acme.spoerlein.net (localhost.spoerlein.net [IPv6:::1]) by acme.spoerlein.net (8.14.4/8.14.4) with ESMTP id o9VJvvN9046220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Oct 2010 20:57:58 +0100 (CET) (envelope-from uqs@FreeBSD.org) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o9VJvvmf046219; Sun, 31 Oct 2010 20:57:57 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Sun, 31 Oct 2010 20:57:57 +0100 From: Ulrich Spoerlein To: Pawel Jakub Dawidek Message-ID: <20101031195757.GO46314@acme.spoerlein.net> Mail-Followup-To: Ulrich Spoerlein , Pawel Jakub Dawidek , src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org References: <201010310921.o9V9LSo4075408@svn.freebsd.org> <20101031160603.GD2160@garage.freebsd.pl> <20101031191119.GM46314@acme.spoerlein.net> <20101031195003.GE2160@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101031195003.GE2160@garage.freebsd.pl> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r214596 - head/bin/rm 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: Sun, 31 Oct 2010 19:57:59 -0000 On Sun, 31.10.2010 at 20:50:03 +0100, Pawel Jakub Dawidek wrote: > On Sun, Oct 31, 2010 at 08:11:19PM +0100, Ulrich Spoerlein wrote: > > On Sun, 31.10.2010 at 17:06:03 +0100, Pawel Jakub Dawidek wrote: > > > IMHO this option should be removed and rm(1) should fail when a user is > > > trying to use it. > > > > No, this is a POLA violation for no apparent gain. The flag has been in > > FreeBSD since at least '94. Remember, that we are in the rope-selling > > business. We empower the users to shoot themselves in the foot. > > > > I, for one, am using the -P option in a certain case where I can be sure > > that ~99% of the data will be obliterated and I'm fine with that. For > > all other cases I'm using geli or gbde (where I can make sure, that data > > is lost). > > The question remains unanswered: If it is not a security feature then > what's the purpose? > > IMHO this is a security feature, just a really lame one. Too many > requirements have to be meet to make it work. > > I don't think you would want to read in GELI or GBDE manual page that it > encrypts the data sometimes, or if all the given requirements are meet. > Of course requirements are fine, but they have to be really clear to the > user and the list should be as short as possible, which is not the case > here. True, this was obviously the case when the feature was introduced, a couple of years ago. As things change constantly, it may never be possible to have it work (and not break silently in the future). > > So we can either fix -P for all cases (impossible), or at least document > > its shortcomings. Documenting them clearly is better than what we had a > > couple of days before. > > I don't argue that the previous version of manual page was better I just > pick your commit to discuss it mentioned functionality further. Sorry, if my post came across a bit harsh. I only tried to document the current behaviour a bit more clearly, and perhaps give the user a warning that this feature might not do what it did 16 years ago. > Maybe we could implement few simple checks which when satisfied don't > emit a warning, ie. if this is UFS, on top of partition, on top of a > slice and on top of a regular SCSI or SATA disk don't emit a warning, > but if there is a doubt, do emit a warning. This might not be trivial, > but might be doable. Alternatively we could always emit a warning. Knock yourself out, code speaks louder than words ... Uli