[BBLISA] Does read only really mean it?

[Dave Allan]

On Fri, Dec 06, 2013 at 09:36:01AM -0500, John Stoffel wrote:
> >>>>> "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.

Not sure if my earlier message got eaten by spam filters.  This
behavior is specified by POSIX and has been the source of extended
debate in the Linux kernel community many of whose members find it as
inexplicable as we do.  See, e.g.:

http://lwn.net/Articles/244829/
http://thread.gmane.org/gmane.linux.kernel/565148
http://en.wikipedia.org/wiki/Stat_%28system_call%29#Criticism_of_atime

I may also be missing the point you're trying to make.  :)

Dave

> 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... :-)
> 
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa