From owner-svn-src-all@FreeBSD.ORG Sun Oct 31 19:11:22 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 8FDC11065670; Sun, 31 Oct 2010 19:11:22 +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 3DEDC8FC12; Sun, 31 Oct 2010 19:11:22 +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 o9VJBKQm021512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Oct 2010 20:11:20 +0100 (CET) (envelope-from uqs@FreeBSD.org) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.4/8.14.4/Submit) id o9VJBKGX021511; Sun, 31 Oct 2010 20:11:20 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Sun, 31 Oct 2010 20:11:19 +0100 From: Ulrich Spoerlein To: Pawel Jakub Dawidek Message-ID: <20101031191119.GM46314@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101031160603.GD2160@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-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 19:11:22 -0000 On Sun, 31.10.2010 at 17:06:03 +0100, 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. > > There is no reliable way to verify if the blocks are really overwritten. > Period. > > If it is not used for security, then I see no other use for it (except > for [1]). > > If it is used for security then we better have a way to give the user > the right answer to the question "is my data really gone?" and don't > make false assumptions or giving answers "we hope so". > > Why there is no reliable way to verify this? > 1. Check file system type (UFS, ZFS). > 2. Check file system configuration (UFS with snapshots?). > 3. Be sure sync(2) the file system and send BIO_FLUSH to all the media > involved (some cheap flash disks lie about BIO_FLUSH support). > 4. Check underlying media (GLABEL provider - no modification to the data). > 5. Check underlying media (ZVOL - data won't be overwritten, but...). > 6. Check ZFS vdevs (on which providers ZVOL's pool is based on). > 7. Check vdevs (GELI - cool, we have encryption). > 8. Check GELI configuration (maybe NULL encryption algorithm?). > 9. Check underlying media (HDD, SSD, swap-backed md(4) device? goto 3). > 10. Check if the sectors weren't remapped while we were overwriting. > > In other words this is soooo complicated that it would simply be too > hard to explain to regular user or implement in rm(1). > > 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). 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. Uli