I happened upon the chattr command and was pleased to see that "s"
means to write zeros (or is it random data?) to the blocks of deleted
files. Cool, except I can't see that it works.
First, deleting a large file with the "s" attribute happens far too
quickly.
Second, I can't see where any of this is implemented in the source
code (as of Red Hat's 2.4.18-17.7.x and straight 2.4.19). The file
fs/ext2/CHANGES talks about how the zero writing was changed to
writing random data--but nothing seems to implement this.
What happened to this feature? Was it too slow or buggy? Did the
Federales force its removal?
(Would this be best implemented as a background scrub and I am missing
a daemon?)
Thanks,
-kb, the Kent who would like to have his notebook not be full of
easily undeletable files.
Kent Borg wrote:
> What happened to this feature? Was it too slow or buggy? Did the
> Federales force its removal?
>
> (Would this be best implemented as a background scrub and I am missing
> a daemon?)
man shred(1)
Much better than anything implemented in-kernel
Jeff
On Thu, Nov 21, 2002 at 01:24:39PM -0500, Jeff Garzik wrote:
> man shred(1)
>
> Much better than anything implemented in-kernel
Yes, but that will only apply to files that I specifically shred. I
hazard that a lot more files than the ones I explicitly "rm" in a day
get deleted by other means. Also, the shred man page even says that
it doesn't know if its "shredding" even happens in the same spot on
disk as the original data resided. It seems this has to happen down
in the file system if there is any hope of it working. And even there
it could use come help from the disk drive to make sure things can be
made to happen where they appear to happen.
-kb
On Thu, 2002-11-21 at 18:39, Kent Borg wrote:
> disk as the original data resided. It seems this has to happen down
> in the file system if there is any hope of it working. And even there
> it could use come help from the disk drive to make sure things can be
> made to happen where they appear to happen.
Very real issue. Your IDE and SCSI disks may randomly leave recoverable
data around if they hit a block that is iffy and mark it bad before it
fails. Flash file systems are very very likely to leave old data around
but fortunately are much smaller and therefore easy to encrypt or blank
wholesale (or indeed blowtorch erase 8))
On Thu, Nov 21, 2002 at 07:20:58PM +0000, Alan Cox wrote:
> Flash file systems are very very likely to leave old data around
Another example of why this needs to be done in the file system. (And
that help is sometimes needed from the "disk" particularly in cases
like flash IDE rives.)
And even if done well in ext2/3 it would not likely be flawless.
Still, it seems one of those cases where perfect can be the enemy of
good.
Something tells me that when the s-attribute was abandoned there were
not many Linux notebooks being carried around. What with RAM having
been limited a swap hard on NiCd batteries.
Also, encryption keys can be coerced in many cases where on-going
secure deletion would remain secure. Linux is picking up other
security features, it might be time to revisit this.
-kb, the Kent who is still curious about the history of the
s-attribute even as the thread threatens to drift off.
If you _really_ care about this, don't use a system that stores your
bytes unencrypted on the platter. Use a crypto loopback filesystem or
somesuch. Otherwise there will always be info leaks.
On Thu, 2002-11-21 at 19:05, Kent Borg wrote:
> Another example of why this needs to be done in the file system. (And
> that help is sometimes needed from the "disk" particularly in cases
> like flash IDE rives.)
The file system can't do it
The flash device won't give you the info to do it
The ide disk wont give you the info to do it
Its possibly a polite hint from the universe to use encryption 8)