
Rm does not permanently delete files - harshasrinivas
https://medium.com/@dawsonbotsford/rm-does-not-delete-files-d90445f51816#.tr38tjfdp
======
throwaway7767
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.

Also, as another commenter already pointed out, this kind of in-place
overwrite is not guaranteed to work on SSDs, and it's also not guaranteed to
work on filesystems with copy-on-write semantics. If you're really concerned
with this, you should be doing full-disk encryption.

~~~
masklinn
> 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.

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

Sure, but installing (a subset of) GNU coreutils is probably going to pull in
a lot fewer dependencies than this JavaScript command line tool. Plus, you can
use ports, no need to mess with a seperate package manager (npm) and the
associated package verification foibles.

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

The "depends on the SSD" is a big one. Various recent forensic papers have
shown that it can take a while until a TRIM'd sector is actually erased by the
firmware.

I still think that if this kind of thing causes worries, full-disk encryption
is really the only sensible solution.

~~~
masklinn
> Sure, but installing (a subset of) GNU coreutils is probably going to pull
> in a lot fewer dependencies than this JavaScript command line tool.

No objection here. Though the original note is right, you just pointed to the
wrong tool:

> I still think that if this kind of thing causes worries, full-disk
> encryption is really the only sensible solution.

And full agreement there.

------
pubby
This is the type of program that should be written in C, not in Javascript
with 9 different dependencies...

~~~
radarsat1
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.

~~~
typicalbender
This. You can bicker all day long about the "correct" language to write
something in but at the end of that long day of going back and forth nothing
actually got written. Better to go with what you know and prototype then weigh
the benefits of rewriting/refactoring it in another language/toolchain.

~~~
mordocai
Except, of course, when it is already written and people are just ignorant of
tools that have been around for many many years.

------
aavotins
Author himself stated that rm has a -P flag, that actually does the same thing
more correctly and more securely:

>Files are overwritten three times, first with the byte pattern 0xff, then
0x00, and then 0xff again, before they are deleted.

Plus the -P flag is available on both GNU and BSD versions of rm. Somehow I
fail to see the user-friendliness factor.

Edit: formatting

~~~
Panino
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.

------
colanderman
The funny thing is, this doesn't even call fsync(2) (which _is_ available in
Node [1]). So the file contents will likely actually _remain_ on disk for some
seconds to minutes thereafter, depending on the OS, file system, and their
configuration.

[1]
[https://nodejs.org/api/fs.html#fs_fs_fsync_fd_callback](https://nodejs.org/api/fs.html#fs_fs_fsync_fd_callback)

~~~
qb45
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.

------
jasonj79
Neat idea, but defaulting to recursive force mode (-rf) is frankly a bit scary
(and irresponsible). A great way to accidentally shoot your own foot off after
you've put it through a meat grinder.

I pity the fool that tries to use this programmatically with a unset or null
var, eg.

    
    
      skrub /$imfucked

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

------
gjvc
see also
[https://en.wikipedia.org/wiki/Srm_(Unix)](https://en.wikipedia.org/wiki/Srm_\(Unix\))

------
jstanley
> Skrub supports file globbing

Why? This is already provided by the shell.

------
brudgers
Defaulting to "rm -rf *" makes me imagine what could possibly go wrong.

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

------
return0
Looking forward to skrub-as-a-service

------
bluedino
>> Before removing your files, skrub first floods the file with zero-filled
bytes.

Should have used /dev/random, and done it 7 times, then you could sell this to
enterprise customers!

------
unlinker
When you decided to write this in JavaScript you should have thought if you
should instead of if you could. ;P

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

------
notanote
If I've understood correctly when I read about this before, programs that
overwrite before unlinking do not work for an SSD. The SSD probably will not
write the data to the same location as the old file. Instead, use fstrim to
have the disk reclaim all free space. After that it's supposed to be
impossible to recover.

[https://en.m.wikipedia.org/wiki/Trim_(computing)](https://en.m.wikipedia.org/wiki/Trim_\(computing\))

~~~
masklinn
> 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

------
devy
Why is Skrub implemented in JavaScript? Do I need an entire nodejs stack setup
to use it?

------
dahart
The old hard-drive lore was that files may still be recoverable until the
contents have been written 7 times - and the government had tools that could
recover previously overwritten data.

Is this still true with SSDs?

~~~
DanBC
> 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.

------
Thaxll
Javascript for a core program seriously...

------
nvk
`srm` works great.

------
noja
_When using the terminal command rm (or DEL on Windows), files are not
actually removed._

Yes they are. As a user, I see a file, type rm file, then it is gone. The file
has been removed.

Yes those parts of that file are possibly recoverable back into the original
file, even without much work, but the file _has_ been removed.

~~~
maze-le
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.

~~~
pritambaral
You are correct that the file contents may remain in memory.

Neither this tool nor GNU shred nor BSD `rm -P` can do anything about it.

