svn commit: r214596 - head/bin/rm

[Ulrich Spoerlein]

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