public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg Freemyer <greg.freemyer@gmail.com>
To: Ted Augustine <taugustine@techpathways.com>,
	Alexey Fisher <bug-track@fisher-privat.net>
Cc: linux-ext4@vger.kernel.org
Subject: xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards]
Date: Fri, 30 Oct 2009 10:20:35 -0400	[thread overview]
Message-ID: <87f94c370910300720s5ea3d780o45fcf32303820a3c@mail.gmail.com> (raw)

On Fri, Oct 30, 2009 at 4:22 AM,  <bugzilla-daemon@bugzilla.kernel.org> wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14354
>
> --- Comment #152 from Alexey Fisher <bug-track@fisher-privat.net>  2009-10-30 08:22:10 ---
> Ted,
> Thank you for explanation :)
> Notice: i learning computer forensic, and was trained to mount all evidence
> systems with "-o ro" to not contaminate it. It seems like ext4 break this
> tradition, so many forensics will surprised  why md5sum do not match.

Ted,  (Alexey there is a response to further down).

I have not followed this thread ultra-closely but Alexey's comment got
my attention.

Ignoring computer forensics, with LVM snapshots, hardware raid array
snapshots, etc. even in the presence of a dirty log, we need to be
able to mount a drive in true read-only fashion fro many backup
operations to function correctly.

XFS added an extra mount flag for that 5 or so years ago.

I hope ext4 either has or will add a true read-only mount option.
Maybe Eric Sandeen remembers the actual drivers for adding that
feature to XFS.

Alexey,

I do computer forensics as part of my job (see my signature). Never
trust the -o ro flag with any filesystem type to keep evidence from
being modified.  It is not designed for forensic use.  And it is hard
to test because it may work in most scenarios, but then under certain
situations, the journal gets applied, or cleared, etc.

fyi: Yes I have read where doing so is advised, but I think that
technique was developed back before Journaled filesystems were common.
 With a modern FS, it is just not a reliable technique in all
situations.

If you must mount a filesystem readonly to perform an exam, then use a
hardware write-blocker to prevent modification.  If the filesystem
cannot be mounted readonly because a writeblocker is in use, then you
know you have issues.

The reality is that in more complex exams, we clone the original
evidence, then perform part of the exam in a live environment.  This
clearly modifies the clone, but not the original.  But the process
should be repeatable by simply making more clones, etc.

Greg
-- 
Greg Freemyer
Head of EDD Tape Extraction and Processing team
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer
Preservation and Forensic processing of Exchange Repositories White Paper -
<http://www.norcrossgroup.com/forms/whitepapers/tng_whitepaper_fpe.html>

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2009-10-30 14:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-30 14:20 Greg Freemyer [this message]
2009-10-30 15:14 ` xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards] Eric Sandeen
2009-10-30 15:31   ` Alexey Fisher
2009-10-30 16:14     ` Eric Sandeen
2009-10-30 16:52       ` Alexey Fisher
2009-10-30 17:13         ` Eric Sandeen
2009-10-30 17:43           ` Duane Griffin
2009-10-30 15:47 ` Alexey Fisher
2009-11-01  5:45 ` Theodore Tso
2009-11-02 21:59   ` Greg Freemyer
2009-11-02 22:53     ` Andreas Dilger
2009-11-02 23:02       ` Eric Sandeen
2009-11-04  8:05         ` Andreas Dilger
2009-11-04 16:20           ` Eric Sandeen
2009-11-03 13:52     ` Theodore Tso

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=87f94c370910300720s5ea3d780o45fcf32303820a3c@mail.gmail.com \
    --to=greg.freemyer@gmail.com \
    --cc=bug-track@fisher-privat.net \
    --cc=linux-ext4@vger.kernel.org \
    --cc=taugustine@techpathways.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox