stux2000 / poorcase

Automatically exported from code.google.com/p/poorcase
0 stars 0 forks source link

Enable rw mount via copy on write layer #1

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. take an image of (a disk with) an NTFS filesystem
2. attempt to mount it with poorcase.
3. Receive "permission denied" because the disks/partitions are read only

What is the expected output? What do you see instead?

What version of the product are you using? On what operating system?
poorcase 1.1 on Linux (Ubuntu 9.10)

Please provide any additional information below.

It would be helpful to be able to mount an NTFS partition without making
changes to the underlying disk image. I had to make changes to poorcase
itself to enable mounting the partitions rw, since the rw option only made
the underlying disk rw, but not the individual partitions. Unfortunately,
since the ntfs-3g driver wants to replay the journal when mounting the FS,
I get "permission denied" errors. Being able to direct those writes to
another block device/file would enable mounting the filesystem, while not
making any changes to the underlying image.

I'd suggest "options=cow cow={filename|device}" as the switch to enable this.

Change made to poorcase to mount partitions rw:

    foreach my $partition (@partitions) {
        open( DMSETUP, "|-", "dmsetup", 
            $opts->{readonly} ? ( "-r", "create" ) : ("create"),
            $opts->{name} . $partition->{num} )
          or die "Couldn't create partition via dmsetup! ($!)";

Original issue reported on code.google.com by rogan.da...@gmail.com on 24 May 2010 at 2:54

GoogleCodeExporter commented 8 years ago
Poorcase supports both read-only and read-write in version 1.1; using the -o 
option similar to the mount command.

For read-write, simply use -o rw (the default is read-only, to keep a forensic 
image sound)

Here's an example:

# poorcase.pl --name disk_img -o rw /path/to/files/*

Original comment by richard.harman on 10 Jul 2010 at 2:49

GoogleCodeExporter commented 8 years ago
I know about the -rw option. And if the objective is to retain a forensic 
image, but you still want the FS to be read write (e.g. you want to boot a VM), 
then you need a copy on write layer so that any changes can be discarded.

Original comment by rogan.da...@gmail.com on 10 Jul 2010 at 4:37

GoogleCodeExporter commented 8 years ago
Here is my attempt at solving it.

Original comment by rogan.da...@gmail.com on 10 Jul 2010 at 10:25

Attachments:

GoogleCodeExporter commented 8 years ago
Oh! I misread your issue, I thought you only wanted read-write support, not 
copy-on-write support.

You implemented what I did at home, but I ran into a brick wall: how do you 
"detect" that an image is mounted read-only via device mapper (the underlying 
stitched together device) and a child device that is a copy-on-write snapshot 
device?

I also couldn't come up with an elegant way to automatically delete the 
temporary copy-on-write snapshot file once the device is "destroyed" via 
--destroy.

To be honest, I simply write a short shell script that made it possible for me 
to turn *any* block device (device mapper or standard /dev/sda or /dev/hda) 
into a device mapper snapshot backed copy-on-write device.  I was about to 
commit that to the SVN repo when I noticed your comment on the issue.

Original comment by richard.harman on 29 Jul 2010 at 2:09