GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  FWIPE0 (1)

NAME

fwipe0 - securely overwrite and delete files

CONTENTS

Synopsis
Description
Options
Bugs
Copyright

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)
Search for    or go to Top of page |  Section 1 |  Main Index


FWIPE0 (1) -->

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.