All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Fisher <bug-track@fisher-privat.net>
To: Greg Freemyer <greg.freemyer@gmail.com>
Cc: Ted Augustine <taugustine@techpathways.com>, linux-ext4@vger.kernel.org
Subject: Re: xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption with  2.6.32-rc1 and upwards]
Date: Fri, 30 Oct 2009 16:47:38 +0100	[thread overview]
Message-ID: <1256917658.3145.20.camel@mini> (raw)
In-Reply-To: <87f94c370910300720s5ea3d780o45fcf32303820a3c@mail.gmail.com>

Am Freitag, den 30.10.2009, 10:20 -0400 schrieb Greg Freemyer:
> 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,
thank you for the comment,
as a student i do not own a hardware write-blocker. But even for normal
admin work, this can cause some frustration. With your comment i
realized that i probably screwed up some raid1 array. I used "-o ro" to
open one of disks. :( need to check it now.


  parent reply	other threads:[~2009-10-30 15:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-30 14:20 xt4 - True Readonly mount [WAS - Re: [Bug 14354] Bad corruption with 2.6.32-rc1 and upwards] Greg Freemyer
2009-10-30 15:14 ` 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 [this message]
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=1256917658.3145.20.camel@mini \
    --to=bug-track@fisher-privat.net \
    --cc=greg.freemyer@gmail.com \
    --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 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.