Where is ext2/3 secure delete ("s") attribute?

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.

man shred(1)

Much better than anything implemented in-kernel

Jeff

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

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

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.

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)