svn commit: r214596 - head/bin/rm

[Pawel Jakub Dawidek]

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.

[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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20101031/eec996b6/attachment.pgp