Home Original page

Secure delete with python

Benjamin Niemann pink at odahoda.de
Mon Sep 6 18:16:52 EDT 2004 
Ville Vainio wrote:
>>>>>>"Benjamin" == Benjamin Niemann <b.niemann at betternet.de> writes:
> 
> 
>     >> fp = open(path, "wb")
>     >> for i in range(os.path.getsize(path)):
>     >> fp.write("*")
>     >> fp.close()
>     >> os.unlink(path)
> 
>     Benjamin> and there is no guarantee that this actually overwrites
>     Benjamin> the old file. The filesystem may choose to write the new
>     Benjamin> content at another location of the disk, leaving the
>     Benjamin> original data untouched.
> 
> Seriously? What OSen are known for doing this? I'd had thought that if
> the file size is unchanged, the data is always written over the old
> data...
I don't know, if there actually is a filesystem that does this, but 
there is no rule (that comes to mind now at least) that forbids it. E.g. 
I could imagine some kind of transactional FS that doesn't change the 
original file until to finish the transaction (=close the file) to avoid 
file corruption, if a program crashes while writing...

Modern filesystem do lots of things most people (including me) can't 
imaging. ReiserFS e.g. packs several small files into one block. If such 
a file grows (perhaps) the data is moved to a block of its own - and the 
old data stays (unreferenced) on disk although you didn't conciously 
made a copy of the file...

But I'm just thinking aloud - don't know if anything of this is true. 
But I except to task of a "secure delete" to be pretty difficult.

> Also, when overwriting a file, it's better to do it several times,
> with alternating bit patterns and "syncing" the disk after each
> pass. Of course even that is not going to guarantee anything because
> it may just go to the hardware cache in the disk unit, but it's
> reasonable if you are overwriting lots of data at once.
> 
> Performing these steps, you'll at least get a good false sense of
> security ;-).
>
More information about the Python-list mailing list