DragonFly On-Line Manual Pages
fwipe0(1) DragonFly General Commands Manual fwipe0(1)
NAME
fwipe0 - securely overwrite and delete files
SYNOPSIS
fwipe0 [ -n ] [ -ttimes ] [ -sSlowness ]
DESCRIPTION
fwipe0 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
successful, 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
Bernstein'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
consequences 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
themselves. For example, Dan Bernstein's serialmail package is
compatible 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^slowness 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
experiment with different slowness settings and different nice
values, and let the author know how well this feature is working
for you. Something around nice -10 fwipe0 -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
seconds 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
settings are to be recommended for various uses. Please give me your
feedback!
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 ALSO
maildirserial(1), echo0(1)
fwipe0(1)