mirror of
https://git.FreeBSD.org/src.git
synced 2024-12-14 10:09:48 +00:00
900c4ed3ca
-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 |
||
|---|---|---|
| .. | ||
| tests | ||
| Makefile | ||
| Makefile.depend | ||
| rm.1 | ||
| rm.c | ||