RE: PATCH - ext2fs privacy (i.e. secure deletion) patch

[Robert White]

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@xxxxxxxxxxxxxxx
[mailto:linux-kernel-owner@xxxxxxxxxxxxxxx] On Behalf Of Theodore Ts'o
Sent: Tuesday, February 03, 2004 10:30 PM
To: Pavel Machek
Cc: the grugq; linux-kernel@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/