[BBLISA] Does read only really mean it?

[John Stoffel]

>>>>> "John" == John P Rouillard <rouilj at cs.umb.edu> writes:

John> In message
John> <CAJFsZ=oBBwr7n_1BcJBO2e-DHJrQWp8mxGEU4tADmBkWz1Bdfw at mail.gmail.com> ,
John> Bill Bogstad writes:
>> On Thu, Dec 5, 2013 at 10:03 AM, Edward Ned Harvey (bblisa4)
>> <bblisa4 at nedharvey.com> wrote:
>>>> From: bblisa-bounces at bblisa.org [mailto:bblisa-bounces at bblisa.org] On
>>>> Behalf Of Alex Aminoff
>>>> 
>>>> Nevertheless, I tested it and unless I messed up my test, an NFS mount
>>>> with -o ro, you read a file on the mounted FS, and the access time is
>>>> updated.
>>> 
>>> Oh - that could explain it right there -
>>> 
>>> I think the client isn't the one doing the update.  I think your
>>> server is updating the last access time on the file, because the
>>> server served the file to the client.  The server doesn't
>>> necessarily know you mounted read-only
>> 
>> That makes a lot of sense.   Alex doesn't say what version of the NFS
>> protocol he is using, but a quick check of the RFC for the MOUNT
>> protocol for NFSv3 (see page 105 for mount protocol
>> http://www.ietf.org/rfc/rfc1813.txt) doesn't seem to give a way for a
>> client to indicate that it wants to mount a filesystem as readonly.
>> Maybe someone who is more familiar with the NFS protocol can confirm
>> this.

John> That is my understanding as well.

John> Also mounting a filesystem ro IIRC used to change some metadata
John> in the filesystem. Maybe last mount time, number of times
John> mounted ... depending on the FS type.

John> I know from forensics work there can be a bunch of things that
John> will change the filesystem/disk state. Hence most forensics
John> people:

John>   1) use a hardware rig that will NOT issue write commands to the
John>      source disk to copy the source disk to a disk they will use
John>      for investigation.
John>   2) use tools that are designed to not mess up the filesystem in the
John>      investigation disk.

John> I.E. they don't consider ro mode sufficient to not change the state of
John> the disk.

I think you're missing the crucial issue here, it's an NFS mounted
filesystem.  Unless the server exports ReadOnly, just because the
client mounts it read-only doesn't mean the server can't update the
atime if it likes.

The true test would be to export RO from an NFS server, either the
host NetApp in this case, or just any other NFS server and see what
happens.  I suspect the atime updates depend more on the server side
than on the client side.

Now someone did make a change to mount with the noatime option, and
that seemed to fix the issue, correct?  And it was still mounted RO,
correct?  

Now how about if you export it purely RO from the server?  Does the
noatime make a difference?   Heh, I've got a Netapp and other systems
at work I can play with, maybe I'll do a quick test volume and let
people know... :-)