]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
rm(1): Formalize non-functional status of -P flag
authorcem <cem@FreeBSD.org>
Sat, 10 Nov 2018 20:26:55 +0000 (20:26 +0000)
committercem <cem@FreeBSD.org>
Sat, 10 Nov 2018 20:26:55 +0000 (20:26 +0000)
commite9e0688cbd2f23352d2eba6a4d94824fe016488f
tree21561415b295ebac254cf0557f60cba9739cdbe6
parentd5379246affad94e0325a9df68a72187bf487ce7
rm(1): Formalize non-functional status of -P flag

-P was introduced in 4.4BSD-Lite2 around 1994.  It overwrote file contents
with a pass of 0xff, 0x00, then 0xff, in a low effort attempt to "really
delete" files.

It has no user-visible effect; at the end of the day, the file is unlinked via
the filesystem.  Furthermore, the utility of overwriting files with patterned
data is extremely limited due to caveats at every layer of the stack[0] and
therefore mostly futile.  At the least, three passes is likely wasteful on
modern hardware[1].  It could also be seen as a violation of the "Unix
Philosophy" to do one thing per tiny, composable program.

Since 1994, FreeBSD has left it alone; OpenBSD replaced it with a single
pass of arc4random(3) output in 2012[2]; and NetBSD implemented partial, but
explicitly incomplete support for U.S. DoD 5220.22-M, "National Industrial
Security Program Operating Manual" in 2004[3].

NetBSD's enhanced comment above rm_overwrite makes a strong case for removing
the flag entirely:

> This is an expensive way to keep people from recovering files from your
> non-snapshotted FFS filesystems using fsdb(8).  Really.  No more.
>
> It is impossible to actually conform to the exact procedure given in
> [NISPOM] if one is overwriting a file, not an entire disk, because the
> procedure requires examination and comparison of the disk's defect lists.
> Any program that claims to securely erase *files* while conforming to the
> standard, then, is not correct.
>
> Furthermore, the presence of track caches, disk and controller write
> caches, and so forth make it extremely difficult to ensure that data have
> actually been written to the disk, particularly when one tries to repeatedly
> overwrite the same sectors in quick succession.  We call fsync(), but
> controllers with nonvolatile cache, as well as IDE disks that just plain lie
> about the stable storage of data, will defeat this.
>
> [NISPOM] requires physical media destruction, rather than any technique of
> the sort attempted here, for secret data.

As a first step towards evental removal, make it a placebo.  It's not like
it was serving any security function.  It is not defined in or mentioned by
POSIX.

If you are security conscious and need to erase your files, use a
woodchipper.  At a minimum, the entire disk needs to be overwritten, not
just one file.

[0]: https://www.ru.nl/publish/pages/909282/draft-paper.pdf
[1]: https://commons.erau.edu/cgi/viewcontent.cgi?article=1131&context=jdfsl
[2]: https://github.com/openbsd/src/commit/7c5c57ba81b5fe8ff2d4899ff643af18c
[3]: https://github.com/NetBSD/src/commit/fdf0a7a25e59af958fca1e2159921562cd

Reviewed by: markj, Daniel O'Connor <darius AT dons.net.au> (previous version)
Differential Revision: https://reviews.freebsd.org/D17906
bin/rm/rm.1
bin/rm/rm.c