Date: Sun, 31 Oct 2010 20:11:19 +0100 From: Ulrich Spoerlein <uqs@FreeBSD.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r214596 - head/bin/rm Message-ID: <20101031191119.GM46314@acme.spoerlein.net> In-Reply-To: <20101031160603.GD2160@garage.freebsd.pl> References: <201010310921.o9V9LSo4075408@svn.freebsd.org> <20101031160603.GD2160@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101031191119.GM46314>