lkml.org 
[lkml]   [2004]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH - ext2fs privacy (i.e. secure deletion) patch
Hi!

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

I see a small problem with that: some "interesting" data, such as file
names, are smaller than a block. With this kind of implementation,
you'd never wipe those.
Pavel
[un-erase no longer works even on ext3, that's nothing new]

--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
-
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/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.131 / U:1.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site