lkml.org 
[lkml]   [2004]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: PATCH - ext2fs privacy (i.e. secure deletion) patch
    Date
    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/

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