Messages in this thread | | | From | "Robert White" <> | Subject | RE: PATCH - ext2fs privacy (i.e. secure deletion) patch | Date | Thu, 12 Feb 2004 14:59:55 -0800 |
| |
At which point, in the presence of the theoretical mount option, it becomes easy to reduce the work load to "a long list of block operations" by making the shredding unconditional.
That is, instead of thinking of it as shredding a file, the (arbitrarily named) "zerofree" mount option is passed and every block that is released from active file system use is zeroed. E.g. file blocks, directory blocks, attribute blocks, everything. That just takes (at the worst) a list/queue and a block-write of a block-sized page containing all zeros (or, better yet, an optionally-user-supplied squeegee pattern.) So take/make the free_block() routine and make it submit a "dirty block" to the I/O buffering system. If the block is immediately re-used then even the write expense amortizes to near zero for clearing that block (or unwritten fragment).
The down side of the simple form comes up when the user unlinks that 20 gig file.
And of course there is no such thing as un-erase for such a media.
On the more positive side this would be _*outstanding*_ for my NV-RAM keychain drive where the files are warranted to be small and I don't want some random person who finds my lost keychain even able to guess about that pesky project I was working on last month.
Meh... 8-)
Rob.
-----Original Message----- From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Theodore Ts'o Sent: Tuesday, February 03, 2004 10:30 PM To: Pavel Machek Cc: the grugq; linux-kernel@vger.kernel.org Subject: Re: PATCH - ext2fs privacy (i.e. secure deletion) patch
On Wed, Feb 04, 2004 at 01:43:18AM +0100, Pavel Machek wrote: > > All that said, the user's content is something that the user could be > > considered responsible for erasing themselves. The meta-data is the part
> > of the file which they dont' have access to, so having privacy > > capabilities for meta-data erasure is a requirement. User data > > erasure... I can take it or leave it. I think it should be automatic if > > at all, but I'm not really that bothered about it. > > Well, doing it on-demand means one less config option, and possibility > to include it into 2.7... It should be easy to have tiny patch forcing > that option always own for your use...
The obvious thing to do would be to make it a mount option, so that (a) recompilation is not necessary in order to use the feature, and (b) the feature can be turned on or off on a per-filesystem feature. In 2.6, it's possible to specify certain mount option to be specifed by default on a per-filesystem basis (via a new field in the superblock).
So if you do things that way, then secure deletion would take place either if the secure deletion flag is set (so it can be enabled on a per-file basis), or if the filesystem is mounted with the secure-deletion mount option.
- Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |