Bad file access on the rise

[Steve Grubb]

On Friday, June 07, 2013 05:02:41 PM Colin Walters wrote:
> On Fri, 2013-06-07 at 22:14 +0200, Miloslav Trmač wrote:
> > On Fri, Jun 7, 2013 at 10:05 PM, Colin Walters <walters at verbum.org> wrote:
> > > On Fri, 2013-06-07 at 20:42 +0100, Matthew Garrett wrote:
> > >> Without further analysis, it doesn't tell us much. Does the code
> > >> attempt
> > >> to open a file O_NOATIME and then fall back to trying it without?
> > > 
> > > It's likely:
> > > https://bugzilla.gnome.org/show_bug.cgi?id=680326
> > 
> > Is there any more rationale for the change available?
> 
> http://lwn.net/Articles/244829/
> 
> > and the line in the sand between updatedb and thumbnail generation
> > admittedly isn't all that clear.)
> 
> Right.
> 
> I guess we really want O_NOATIME_IF_POSSIBLE.  Although I wonder if
> there's any reason not to just silently ignore O_NOATIME if it's not
> permitted, rather than force apps to double open().

Hmm...sounds like kernel change. But in the meantime, most of the offenders I 
see seem to have something to do with loading icons:

name=/usr/share/icons/gnome/16x16/mimetypes/x-office-document.png 30
name=/etc/pki/tls/certs/localhost.crt      25
name=/usr/share/icons/hicolor/48x48/apps/firefox.png 11
name=/usr/share/icons/hicolor/22x22/apps/firefox.png 10
name=/usr/share/icons/hicolor/24x24/apps/firefox.png 9
name=/usr/share/icons/hicolor/32x32/apps/firefox.png 9
name=/usr/share/icons/gnome/16x16/actions/window-close.png 9
name=/usr/share/icons/hicolor/256x256/apps/firefox.png 8
name=/usr/share/icons/hicolor/16x16/apps/firefox.png 8
name=/usr/share/icons/gnome/24x24/actions/go-up.png 7
name=/usr/share/icons/gnome/24x24/actions/go-down.png 7
name=/usr/share/icons/gnome/24x24/places/folder.png 7

I think we can assume root owns the icons which mean calls with NOATIME as a 
normal user session will fail. Maybe the call that opens the icon can be 
switched to a regular open?

Thanks,
Steve