Rm does not permanently delete files

Looking at man shred, apparently one can shred stdout.

> This functionality already exists in GNU coreutils, it's done by the shred(1) command. No need to install any extra third-party software, shred is already installed.

That's only true for GNU-based userlands, not BSD-based ones.

> Also, as another commenter already pointed out, this kind of in-place overwrite is not guaranteed to work on SSDs

And if the system properly TRIMs it might not be necessary at all, though that greatly depends on the SSD.

I read comments before clicking the link and thought you were kidding... At least it doesn't run in the cloud and require files to be uploaded there.

Though, on second thought, this cloud service idea has some nice potential for evil :)

This is the sort of program that has been written in C, and is probably already included on most systems.

True. But no harm in getting it off the ground quickly before optimising. Git was written in Perl originally, and ported bit by bit to C. I think this shows it can be a good way to work -- prototype quickly, then optimise.

Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.

// quoting https://blog.codinghorror.com/the-principle-of-least-power/

That actually seems to be a BSD extension not supported by GNU coreutils/fileutils.

On OpenBSD, -P overwrites once. It used to be 3, like the author states, but was changed to one pass since multiple overwrites are pointless on mechanical disks. On SSDs you need ~20 passes of the entire drive to remove ~all data, so I doubt 3 passes of a single file on an SSD would accomplish what the person wants.

As an aside, it has never been demonstrated that multiple overwrites improve overwriting. In other words, it's never been demonstrated that data overwritten just once can be recovered. Until that happens I'll agree with other folks that multiple overwrites are a waste of time and electricity, and that FDE is a much more reasonable (not fool-proof, just reasonable) way to make data unavailable to unauthorized persons.

> Plus the -P flag is available on both GNU ...

    [pritam@PritePad ~]$ cat /etc/lsb-release 
    LSB_VERSION=1.4
    DISTRIB_ID=Arch
    DISTRIB_RELEASE=rolling
    DISTRIB_DESCRIPTION="Arch Linux"
    [pritam@PritePad ~]$ touch t
    [pritam@PritePad ~]$ rm -P t
    rm: invalid option -- 'P'
    Try 'rm --help' for more information.

`man rm` does suggest looking at shred(1) in the SEE ALSO section

Or years if the OS crashes afterwards.

I also wonder what happens if the file is deleted before the zeros are flushed. Is there some implicit flush, triggered by metadata changes, which saves the day? No idea.

If you're going to do it in a script you'll need to set those flags anyway, won't you?

Pretty sure that was just an example to demonstrate that skrub uses the -rf options by default.

We are JavaScript. We are the Collective. You will be assimilated. Resistance is futile.

> Instead, use fstrim to have the disk reclaim all free space. After that it's supposed to be impossible to recover.

That's not quite true. TRIM simply tells the SSD that the corresponding block is not in use anymore, it doesn't tell the SSD what to do with it.

The controller will usually unmap the physical block and schedule it for erasure but usually not erase it immediately unless it doesn't have any free block to remap. And it will return zeroes if the block is read.

The data is recoverable at that point (until the block is actually erased) and can remain so for a fairly long time[0] if the attacker can either bypass the SSD controller or can physically access the raw flash memory.

[0] depending on storage pressure and the exact make and recycling strategy of the SSD

Unlikely, because while hard drives use magnetic storage (where a few magnetic domains may still point in the direction of the previous magnetization, SSDs store bits in discrete logic gates - meaning that even if there is a trace, the chip would need to be disassembled and the gates examined with an electron microscope one-at-a-time. Furthermore, it's less likely that data can survive a single rewrite, given the mechanism used (instead of bytes being changed in-place, whole blocks are erased completely and then re-written - which means the erasing is less delicate because it doesn't need to avoid flipping neighboring bits).

> and the government had tools that could recover previously overwritten data.

That wasn't true. But, since we can't prove it's not true precaution says you should over-write drives a few times with pseudo random data.

SSDs are a bit more worrying because end users don't have full control.

But with physical drives or SSDs if the data is that important you should be looking at physical destruction, rather than just over writing.

FWIW: This seems to mostly be lore. See http://www.nber.org/sys-admin/overwritten-data-guttman.html

Note also "Since writing the above, I have noticed a comment attributed to Gutmann conceding that overwritten sectors on "modern" (post 2003?) drives can not be read by the techniques outlined in the 1996 paper, but he does not withdraw the overwrought claims of the paper with respect to older drives."

(the comment is at http://seclists.org/bugtraq/2005/Jul/464)

As for SSD's, it's harder to say because of wear leveling and bad sector replacement. They internally have their own translation layers, and so the overwritten data may not end up where the original data was (this is itself a complicated topic. http://codecapsule.com/2014/02/12/coding-for-ssds-part-3-pag... is a reasonble intro)

However, one neat thing about them is that there are plenty of SSD's that do hardware encryption by default. When they get init'd, they set the key. You can reset the key, and then, pretty much, assuming the SSD's have not been backdoored by our security agencies, it doesn't matter what you do ;)

This assumes you just want to destroy all the data though, not just some of it.

Do you remember the dd challenge where they offered money to any company that could recover a drive that had been zeroed over once with dd? Nobody ever took it.

The file, yes, but not the file contents. Worst of all, if you opened the file recently with any process, there is a pretty good chance that the file-descriptor can be found in:

  /proc/

somewhere.

And with that in mind you can use a combination of lsof, grep, sed or any other tool to still read the file as it was.