There are a number of purpose built tools to do this job already. The one that comes to mind first is 'shred'. shred is installed by default on all Redhat and Ubuntu systems (in coreutils package on both systems). It is also installed on my RaspberryPi, so, it is ubiquitous.
Shred does similar things to what your script does, but it will be faster, and more secure, presumably. Running:
shred -u file
will repeatedly overwrite, and then delete the file.
Note that shred itself contains in the documentation:
CAUTION: Note that shred relies on a very important assumption: that the file
system overwrites data in place. This is the traditional way to do
things, but many modern file system designs do not
satisfy this assumption. The following are examples of file systems
on which shred is not effective, or is not guaranteed to be effective
in all file system modes:
* log-structured or journaled file systems, such as those supplied with AIX and
Solaris (and JFS, ReiserFS, XFS, Ext3, etc.)
* file systems that write redundant data and carry on even if some writes fail,
such as RAID-based file systems
* file systems that make snapshots, such as Network Appliance's NFS server
* file systems that cache in temporary locations, such as NFS version 3 clients
* compressed file systems
These same cautions apply to your code.
There is really only one way to manage content that you need to securely erase later, and that is to encrypt the data before you store it, or to store it in an encrypted filesystem.
Deleting the file then is as simple as 'forgetting' the key, or corrupting critical/small parts of it.
The bottom line is that since almost all Linux implementations now use ext3 or some other Journaled file system, that your secure erase is not likely going to be secure enough.
Assuming the process would actually work in your setup....
As for your actual script, the code is neat enough, and the command-line arguments are handled OK. There are still a number of problems though:
you have no error-handling for any of your
dd commands. if all the dd commands fail (perhaps someone is running in a
chroot jail and
/dev/urandom are not accessible), but the
rm works, it will seem like the process succeeded, but you have not actually changed any bytes on disk... which is bad.
A user who runs your command as:
securedelete "My Document"
would expect "My Document" file to be overwritten, but you have not quoted the
$1 in any of the use-cases, so the
rm commands will fail with things like:
dd if=/dev/zero of=My Document bs=$filesize count=1
Actually, that's a good example of a bad failure. All the dd commands will fail, doing nothing, and then, at the end, you will have:
rm -f -- My Document
which will force-delete two files, one called
My the other called