Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rm does not permanently delete files

medium.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: Rm does not permanently delete files

#32

Post by GalacticDomin8r »

masklinn wrote: post #10
throwaway7767 wrote: post #6

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…

> 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's only true for GNU-based userlands, not BSD-based ones.

"rm -P" with the same caveats as the GNU implementation.

Re: Rm does not permanently delete files

#36

Post by Jaepa »

masklinn wrote: post #10
throwaway7767 wrote: post #6

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…

> 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…

for BSD-base systems there is srm (secure remove), which overwrites, renames, & trucates before unlinking.

https://www.freshports.org/security/srm/

Re: Rm does not permanently delete files

#37

Post by DannyBee »

masklinn wrote: post #10
throwaway7767 wrote: post #6

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…

> 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's only true for GNU-based userlands, not BSD-based ones. "

  RM(1)                     BSD General Commands Manual                    RM(1)
...

  -P          Overwrite regular files before deleting them.  Files are
              overwritten three times, first with the byte pattern 0xff,
              then 0x00, and then 0xff again, before they are deleted.

Re: Rm does not permanently delete files

#38

Post by rlidwka »

pubby wrote: post #5

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

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/

Re: Rm does not permanently delete files

#39

Post by Panino »

aavotins wrote: post #15

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

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.

Re: Rm does not permanently delete files

#40

Post by DannyBee »

dahart wrote: post #22

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?

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.

Post reply on HN