All of lore.kernel.org
 help / color / mirror / Atom feed
From: Samuel Tardieu <sam@rfc1149.net>
To: linux-ext4@vger.kernel.org
Subject: Shred mount option for ext4?
Date: 31 Oct 2006 11:36:11 +0100	[thread overview]
Message-ID: <87hcxkpyas.fsf@willow.rfc1149.net> (raw)

Sorry if this has been discussed already, I couldn't find anything in
the list archive about it. What about adding the possibility of
shredding or erasing free blocks on an ext4 filesystem?

I value my privacy and the privacy of the people I host, and I often
use shred(1) when erasing files from my server. The goal is to avoid
that either a hacker or a post-mortem analysis gets ancien data from
my disk. There are three problems with this approach:

  - I may forget to use shred sometimes

  - some files are automatically created and then removed (mails in
    spool)

  - data may be replicated in the journal and thus still present on
    disk

I could use an encrypted filesystem everywhere, but in many countries,
one is required to reveal her encryption key to authorities if they
have a court order (UK for example).

I think it would be quite easy to add a mount time option to ext4
filesystems asking that freed blocks are cleared or erased with random
data? We could have for example:

  - free=clear|zero|shred (default "clear", do nothing, "zero" means
    writing zeroes over the block, useful against attackers trying to
    recover data from a file system without physical access to it, and
    "shred" useful against post-mortem analysis of the physical
    surface)

  - shred-passes=N (number of passes when using the "free=shred"
    option, a negative number meaning writing values from 0 to -N onto
    the block)

Some people (me included) would most likely accept the time penalty of
using this option on selected filesystems (as well as the reduced
lifetime of the disks because of the extra writes).

I would contribute a proof-of-concept code, but I'm going to leave for
a one-month vacation and will have a very bad connection until
December. However, if noone jumps on that, I will likely code that
when I go back unless someone beats me on it. In the meantime, I'd
like to get people thoughts about it.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/

             reply	other threads:[~2006-10-31 10:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-31 10:36 Samuel Tardieu [this message]
2006-10-31 12:32 ` Shred mount option for ext4? Erik Mouw
2006-10-31 13:02   ` Samuel Tardieu
  -- strict thread matches above, loose matches on Subject: below --
2006-10-31 20:14 Nikolai Joukov
2006-11-01 16:17 ` Andreas Dilger
2006-11-01 16:38   ` Ric Wheeler
2006-11-01 16:52     ` Nikolai Joukov
2006-11-01 17:20       ` Erez Zadok
2006-11-01 16:57   ` Wolber, Richard C
2006-11-20 10:52     ` Rupesh Thakare

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87hcxkpyas.fsf@willow.rfc1149.net \
    --to=sam@rfc1149.net \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.