Date: Sun, 31 Oct 2010 17:06:03 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Ulrich Spoerlein <uqs@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: <20101031160603.GD2160@garage.freebsd.pl> In-Reply-To: <201010310921.o9V9LSo4075408@svn.freebsd.org> References: <201010310921.o9V9LSo4075408@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--q9KOos5vDmpwPx9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 . 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. [1] When we have UFS file system on top of ZVOL with compression enabled, overwriting file content with zero bytes should convert blocks into holes, which will free some space - a usage definitely not worth keeping -P around. :) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --q9KOos5vDmpwPx9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEUEARECAAYFAkzNk+sACgkQForvXbEpPzRhDgCYhFyFcevDUrN4msCrn8c0rADf UwCeKa5aw17CNdnoVcXfXXXJdr6m+AI= =9aU6 -----END PGP SIGNATURE----- --q9KOos5vDmpwPx9o--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101031160603.GD2160>