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

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

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

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."
  • 5
    \$\begingroup\$ Security.SE has the opinion that just overwriting the data is not enough due to caching and write distribution. \$\endgroup\$ Nov 3 '14 at 11:02
  • 1
    \$\begingroup\$ Sure, use shred filename, which likely has better performance, and certainly better security aspects. \$\endgroup\$
    – rolfl
    Nov 3 '14 at 12:23
  • 2
    \$\begingroup\$ This script makes the assumption that the overwriting of the file will overwrite the same blocks that the file originally resided on, and also assumes that the writes happen immediately. Neither of these assumptions are certain. As a result, the answer to 'Is this a good way of doing the thing I want to do?' is 'No'. The right answer though, would be too broad for Code Review. As a result, I am closing this question as 'too broad'. \$\endgroup\$
    – rolfl
    Nov 3 '14 at 12:35
  • 7
    \$\begingroup\$ @rolfl I think that is exactly the point the code review. I had no idea about the overwriting the same blocks assumption, this was my try on overwriting a file. The answer could have been, no this is not right because you assume this with overwriting like that. Just closing the question because the script is wrong is kind of ...rough. \$\endgroup\$
    – Erfan
    Nov 3 '14 at 13:12
  • \$\begingroup\$ @Erfan - let's chat about this in The 2nd Monitor \$\endgroup\$
    – rolfl
    Nov 3 '14 at 13:15

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.

  • \$\begingroup\$ A very important caution to add to that list from shred: solid state drives. By design overwrites will go to empty flash blocks (not the same flash block currently occupied), leaving "overwritten" data particularly susceptible to recovery. \$\endgroup\$
    – nobody
    Nov 3 '14 at 18:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.