svn commit: r214596 - head/bin/rm

[Alexander Best]

On Sun Oct 31 10, 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.

i suggested to remove it and also came up with a patch [1], but quite a lot of
developers decided the -P option should be kept rather than removed.

although there was quite an elaborate discussion about it that followed after
des@ commited r214431, i still haven't got the slightest idea just WHY it
should stay. ;)

[1] http://www.mail-archive.com/svn-src-head@freebsd.org/msg07404.html

cheers.
alex

> 
> 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. :)
> 
> -- 
> Pawel Jakub Dawidek                       http://www.wheelsystems.com
> pjd at FreeBSD.org                           http://www.FreeBSD.org
> FreeBSD committer                         Am I Evil? Yes, I Am!



-- 
a13x