rm | Cleaning up recycle bin

[Michael Schuster]

You also need to consider COW semantics when using ZFS: You'll never
actually overwrite existing data, new data will be written to new disk
blocks, so while the original data may not be visible to the user anymore
with regular file system tools, depending on things like disk activity and
how full the disk is, the old data you wanted overwritten may actually
still be around on the storage media for a while.
(I'd advise you to research "zfs" and "secure data removal" or something
like that to find out what the current solution(s) to this problem is/are).

HTH
Michael

On Mon, Feb 24, 2020 at 3:54 PM Kevin P. Neal <kpn at neutralgood.org> wrote:

> On Sun, Feb 23, 2020 at 06:49:08PM +0100, Polytropon wrote:
> > On Sun, 23 Feb 2020 14:05:35 +0100, Jos Chrispijn wrote:
> > > I read somewhere that using the rm command does not phsyically remove
> > > the 'deleted' files when using the command in a terminal session. Can
> > > you tell me how/where I can really remove these files (as per user
> > > account or in general)? Thanks!
>
> > If you also want to remove the _data_ (read: the former file
> > content), you need to overwrite the file's content with a
> > random pattern or with zeros first. This can be done with
> > the dd tool. There is also a port called "secure rm" (srm)
> > that achieves the same "by overwriting, renaming, and
> > truncating it before unlinking". You can find its manpage
> > with further suggestions here:
> >
> > https://www.freebsd.org/cgi/man.cgi?query=srm
> >
> > However, this does not change things related to disk space
> > becoming free. So when intending to simply remove files
> > without any "recycle bin" nonsense, rm is the way to go.
>
> The thing about security is that often all you can do is raise the cost
> of an attack. If the cost is high enough then you can often make an
> attacker
> find a better use of their time.
>
> Using forensics tools on a disk to recover a file that has been deleted
> is pretty low cost. Still, I wouldn't expect the average street criminal
> to be able to recover the files. The guy that broke into my house and
> stole a jar of coins couldn't do it, for example.
>
> Filling the filesystem will probably clobber the leftover file's data
> it's true. That makes an attack more expensive/harder, but if you are
> using an SSD or a "shingled" (SMR?) hard drive then you aren't done yet.
>
> For example, SSD's will do wear leveling, and that means that a write to
> a block at a particular offset will typically end up going to a different
> physical block on the drive. The previous contents won't be available
> to normal use, but tools no doubt exist that can recover the previous
> block.
>
> So, what's the threat you are trying to protect yourself from?
> --
> Kevin P. Neal                                http://www.pobox.com/~kpn/
> "Oh, I've heard that paradox a couple of times, but there's something
> about a cat dying and I hate to think of such things."
>   - Dr. Donald Knuth speaking of Schrodinger's cat, December 8, 1999, MIT
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "
> freebsd-questions-unsubscribe at freebsd.org"
>


-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'