> Having thought this over some more, if a > shred/scramble/scrub command is created in its own > right, then a number of new features could be added > that do not currently exist.
> - The command could be writen to protect a single > file, or, it could also write to an entire file > system/media. These won't share much beyond what patterns to write and how many times. > - The command could offer many types of randomising > possiblities, eg the current 0xff, 0x00, 0xff; or > perhaps /dev/random could be written; or perhaps the > user could specify exactly what is to be used to > overwrite the file/file system - from memory some > large organistations (govt depts) have specific rules > about how files/file systems should be overwritten > before old medie is thrown out and replaced (so no-one > can scavenge the media and read sensitive data) IMHO even this does not address paranoia very well. The point of rm -P is to make sure freed blocks on the disk don't have any useful information. But if the bad guy can read the disk *while* it also holds other files on it, the battle is already lost as presumably he can also read data in live files. If you are using rm -P in preparation to throwing a disk away, you may as well just use a whole disk scrubber. If you are using rm -P to prevent a nosy admin to look at your sensitive data, you will likely lose. He can easily replace rm with his own command. A separate scrub command may help since you can verify the data is erased. This is not to say rm -P or scrub is not helpful. If you know what you are doing it is perfectly adequate. But if you don't or you make mistakes, it will give you a false sense of security. For example, once a file is unlinked through some other means (such as mv) you don't have a handle on it any more to scrub. Basically you lost the ability to scrub your data due to a mistake. Worse, editing such a file may free unscrubbed blocks. A separate command won't help. This is why I suggested to have the system do this for you (through a mount option -- I don't care enough to want to implement it). > Kind of thinking out loud here, apologies if its > noisy, Tim. If the end result is clear headed go right ahead! _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
