Am 25.01.2015 um 12:42 schrieb Alexander Holler:
Now, after I ended up into flaming a lot (sorry again, but this topic
made me angry for so long and I had to spent too much time to get rid of
unwanted content and answering other peoples question in regard to that
topic), I should offer something more useful.
So I've written down in some short words, how I think it could be done:
First offer a syscall named sunlink() (or whatever name) which fails if
it can't overwrite or securely trim the contents of a file before
deleting it.
That could be done like this:
(1) If it's a SSD or MMC without offering "Secure Trim" fail.
(2) If it's a plain FLASH or conventional harddisk where writing a block
means that block will be overwritten or if it's a SSD or MMC with
"Secure Trim) go on with
(3)
(2a) for network devices and similiar stuff either propagate sunlink()
down or fail
(2b) if in doubt, fail (it's better to inform the user that securely
deleting a file failed than to go on silently without really deleting a
file).
(3) Identify the blocks which contain the file contents (should be
doable by using the same mechanisms used to read and write a file)
(4) Mark the file as deleted
(5) Overwrite or securely trim blocks which can be deleted completely
(6) Build new blocks for blocks which can only partly deleted because
they contain information still used by the FS or other files
(7) Instruct the FS to us the new blocks instead of the old ones
(8) Overwrite or securely trim the old blocks which previously contained
partly information of other stuff.
Afterwards use that new syscall in shred.
Of course, this is just a totally simplified instruction in regard to
how complicated filesystems have become, but I think there isn't any
black magic involved in offering the user a simple way to really delete
files.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
