fwipe0(1)fwipe0(1)NAMEfwipe0 - securely overwrite and delete files
SYNOPSISfwipe0 [ -n ] [ -ttimes ] [ -sSlowness ]
DESCRIPTIONfwipe0 reads a list of filenames on standard input, each one followed
by a 0-byte. If a filename refers to a regular file, then fwipe0
attempts to overwrite the file times times with 0's and 1's. If suc‐
cessful, fwipe0 attempts to delete the file.
For each file, fwipe0 prints a response to stdout consisting of the
filename, followed by a 0-byte, a status byte, a human-readable message
and a newline. The status byte is 'Z' for temporary failure, 'D' for
permanent failure, and 'K' for success.
The output of fwipe0 is suitable for secure parsing by other programs.
One program which already understands this message format is Dan Bern‐
stein's maildirserial program, distributed as part of his serialmail
package.
After each pass overwriting a file, fwipe0 syncs the data to disk. That
makes sure that your data is really overwritten on disk, not just in
some memory buffer. This should even work if your files are mounted
over NFS. However, some disks may have their own internal buffers,
which would defeat fwipe0. If you are really concerned about the con‐
sequences of a privacy breach, then you should throw your hard drive in
a vat of molten steel.
If fwipe0 encounters any error while erasing a file, then it refuses to
delete the file. That way, data which was not overwritten is still
where you can find it to deal with in some other way. Deleting files
which weren't overwritten is, of course, a privacy leak.
If a file grows while fwipe0 is overwriting it, then fwipe0 will not
delete it. That way, if somebody is still appending data to the file,
the data will not disappear where you can't easily find and deal with
it.
OPTIONS-n Erase the file, but do not delete it. This is provided for the
sake of embedding applications which want to do deletions them‐
selves. For example, Dan Bernstein's serialmail package is compat‐
ible with fwipe0. You can use it to erase the contents of a
maildir with the command maildirserial dir prefix fwipe0-n.
-ttimes
Overwrite the file times times. Default is 5.
-sSlowness
Experimental: introduce a delay factor out of niceness to other
users. Since overwriting a file is very I/O intensive, fwipe can
make the system fairly unresponsive to interactive users. Lowering
the priority using nice is a good idea, but it doesn't help
responsiveness much--most of the work is being done by the bdflush
daemon, which runs at kernel priority. The -sSlowness option adds
a periodic pause during operation, which allows lowered priority
to actually kick in and schedule other tasks. The argument can be
any number between 1 and 32, with 1 giving the largest slowdown.
When "slowness" is turned on, fwipe0 sleeps after writing 2^slow‐
ness blocks. This is an embarrassment of variety, I realize: using
a slowness below 11 or 12 results in ridiculously long execution
times, and values above 16 or 17 seem to eliminate most of the
benefit of the feature (but might still be useful in conjunction
with higher nice values).
Note that fwipe0 does not monkey with its own priority; you still
have to use nice to lower the priority of fwipe0. Please experi‐
ment with different slowness settings and different nice values,
and let the author know how well this feature is working for you.
Something around nice -10fwipe0-s15 is recommended as a starting
point.
The duration of the sleep starts at 1 second, and then gradually
increases using the same "quadratic backoff" scheme as qmail-send.
The rationale is that small file wipes are not affected much by
this backoff, but large files on the other hand take a long time
to wipe anyway--so who cares if a 1GB wipe takes 2 hours or 4
hours? The wait is determined by counting the number of times
fwipe0 invokes sleep(). The sleep duration is the largest perfect
square <= that count. So the first three sleeps are 1 second
long; the next five are 4 seconds long; the next seven are 9 sec‐
onds long, etc. The number of blocks written between sleeps is
constant and is determined by the -sslowness argument as explained
above.
BUGS
At the moment, fwipe0 always returns a "temporary error" status on
failure. That may change, if I ever decide which errors are temporary,
and which are permanent.
The "slowness" feature is highly experimental--it has no impact on the
security or reliability of fwipe, but I haven't the foggiest what set‐
tings are to be recommended for various uses. Please give me your feed‐
back!
Also, there is a race condition when fwipe0 decides whether a file has
grown before deleting it. It is possible for someone to append data to
a file after fwipe0 has decided to delete it, and before it is deleted.
This might result in some information leaking to disk without being
wiped.
Users of fwipe0 should generally make sure that they control the files
they are wiping, and that they aren't running anything which might keep
appending to the file.
Admins might want to occasionally fill the disk with data, and then run
fwipe0, to erase information which was insecurely deleted (either by rm
or through the fwipe0 weaknesses already mentioned). Also, don't forget
degaussing, and vats of molten steel.
COPYRIGHT
Copyright (c) 2000, Len Budney. All rights reserved. fwipe0 is made
available under the terms of the BSD license.
SEE ALSOmaildirserial(1), echo0(1)fwipe0(1)
