[BBLISA] Does read only really mean it?

[Tim Wilde]

It wasn't so much eaten by spam filters as "contained the word POSIX so
everyone's eyes glazed over and we went into comas" :)

On Fri Dec 06 2013 at 1:14:48 PM, Dave Allan <dave at dpallan.com> wrote:

> 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@
> 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
>
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.bblisa.org/pipermail/bblisa/attachments/20131206/ac816b9d/attachment.htm