From owner-svn-src-head@FreeBSD.ORG Mon Nov 1 14:22:47 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 EEDAF106566B; Mon, 1 Nov 2010 14:22:47 +0000 (UTC) (envelope-from kensmith@buffalo.edu) Received: from localmailA.acsu.buffalo.edu (localmail.buffalo.edu [128.205.5.196]) by mx1.freebsd.org (Postfix) with ESMTP id B7E178FC17; Mon, 1 Nov 2010 14:22:47 +0000 (UTC) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 6E5C1B51C; Mon, 1 Nov 2010 10:16:05 -0400 (EDT) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id 138D4B56E; Mon, 1 Nov 2010 10:16:03 -0400 (EDT) Received: from mweb1.acsu.buffalo.edu (mweb1.acsu.buffalo.edu [128.205.5.238]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id F3829B54C; Mon, 1 Nov 2010 10:16:02 -0400 (EDT) Received: from [128.205.32.76] (bauer.cse.buffalo.edu [128.205.32.76]) by mweb1.acsu.buffalo.edu (Postfix) with ESMTP id 359D25B0043; Mon, 1 Nov 2010 10:15:52 -0400 (EDT) From: Ken Smith To: Ulrich Spoerlein In-Reply-To: <20101031191119.GM46314@acme.spoerlein.net> References: <201010310921.o9V9LSo4075408@svn.freebsd.org> <20101031160603.GD2160@garage.freebsd.pl> <20101031191119.GM46314@acme.spoerlein.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-bS9egv1BU3VSzXx7UbUT" Date: Mon, 01 Nov 2010 10:15:51 -0400 Message-ID: <1288620951.3596.32.camel@bauer.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 FreeBSD GNOME Team Port X-PM-EL-Spam-Prob: : 8% Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Pawel Jakub Dawidek 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: Mon, 01 Nov 2010 14:22:48 -0000 --=-bS9egv1BU3VSzXx7UbUT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Sun, 2010-10-31 at 20:11 +0100, Ulrich Spoerlein wrote: > 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 > > >=20 > > > 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 . > >=20 > > I'm sorry for jumping so late into the subject, but if it is not a > > security feature than what other purpose has left? > >=20 > > Really guys, this option is useless. > >=20 > > There is no reliable way to verify if the blocks are really overwritten= . > > Period. > >=20 > > If it is not used for security, then I see no other use for it (except > > for [1]). > >=20 > > 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". > >=20 > > 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 dat= a). > > 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. > >=20 > > In other words this is soooo complicated that it would simply be too > > hard to explain to regular user or implement in rm(1). > >=20 > > IMHO this option should be removed and rm(1) should fail when a user is > > trying to use it. >=20 > 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. Just playing Devils' Advocate... If the removal of -P were done as part of a new branch the POLA argument is moot if it's judged you are a bit off on the "no apparent gain" aspect. And the rope selling argument also only applies so far. One could argue having our installer by default leave a machine set up so SSH was enabled, remote root logins were allowed, and no initial password set up for root is fine because we're in the rope-selling business and for some portion of the user base that's just fine. I know that's extreme but that's the point, I'm saying it's hard to figure out exactly where the line is between activities that are ill-advised versus those that are just plain stupid sometimes. So, please, given all the attention being given to the security aspects of users properly erasing data they should erase I'd prefer we focus on whether providing -P at all is flat out lying and base the decision about whether it should go based on that. Lots of things we thought were OK back in 1994 we've changed our minds about since then. > 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). This strongly backs up Pawel's argument that the existence of -P is a lie. > 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. As I said above, with re@ hat on since the claim of POLA above is slightly based on branch/release guidelines, I think removal of -P is also still an option if it's decided -P is a lie. --=20 Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodor Geisel | --=-bS9egv1BU3VSzXx7UbUT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEABECAAYFAkzOy44ACgkQ/G14VSmup/Z+oQCgjSGR8CI1gDTxsudzEsszAICr 9/AAoJU+/HB2kCgXNKtfOavMg8C6sO7A =tOcT -----END PGP SIGNATURE----- --=-bS9egv1BU3VSzXx7UbUT--