Securely delete a file

I am trying to write a script to securely delete a file. What I am intending to do is to pad the file with /dev/zero once, and then with /dev/urandom three times and then delete the file.

For now the user only accepts one file at a time and the functionality is limited, if I am on the right track then I'll add more options later for recursive, verbose mode off/on, etc. Is this a good way of doing the thing I want to do? Both from performance aspect and the security.

#! /bin/bash

if [ "$#" -eq 0 ]; then
    echo "ERR: Arguement is not supplied." 1>&2
    exit 1
elif [ "$#" -gt 1 ]; then
    echo "Too many arguments have been provided." 1>&2
    exit 1
fi

if [ ! -f "$1" ]; then
    echo "File $1 is not found" 1>&2
    exit 2
fi

filesize=$(stat -c "%s" "$1")
if [ "$filesize" -eq 0 ]; then
    filesize=1
fi

echo "Padding file with zeros"
dd if=/dev/zero of=$1 bs=$filesize count=1

echo "Padding file with randoms, first time"
dd if=/dev/urandom of=$1 bs=$filesize count=1

echo "Padding fxile with randoms, second time"
dd if=/dev/urandom of=$1 bs=$filesize count=1

echo "Padding file with randoms, third time"
dd if=/dev/urandom of=$1 bs=$filesize count=1

echo "Deleting the file"
rm -f -- $1

echo "File is securely deleted, or at least we think so."

Concept Review

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.
Code Review

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/zero 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 dd and 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 Document.

StackExchange Code Review Q#68729, answer score: 11