path watcher

path watcher

[John Haxby]

Hello,

We have an internal group auditing updates to files but who would like
to be able to monitor the actual modification rather than the possible
intent to modify.

The example they gave is that some program opens a file
O_WRONLY|O_APPEND but in most cases it does not subsequently write to
the file.  For them, the usual auditctl -p path -w wa causes lots of
false positives.

Historically, I know, that -w wa is triggered by the open(2) flags
rather than actual modifications because "[t]he read & write syscalls
are omitted from this set since they would overwhelm the logs."  Reading
this again now, it looks a little specious as it seems quite easy to
overwhelm the logs anyway.

Is there any reason why a file watcher should not use the fsnotify
FS_ACCESS/MODIFY/ATTRIB masks before I go haring off to try to implement
that?

jch

Re: path watcher

[Steve Grubb]

Hello,

I had hoped some kernel guys would have jumped in here to answer...but I'll 
take a stab at it.

On Friday, August 22, 2014 04:31:24 PM John Haxby wrote:
> We have an internal group auditing updates to files but who would like
> to be able to monitor the actual modification rather than the possible
> intent to modify.

That would be a nice addition.

> The example they gave is that some program opens a file
> O_WRONLY|O_APPEND but in most cases it does not subsequently write to
> the file.  For them, the usual auditctl -p path -w wa causes lots of
> false positives.

I have asked some problematic apps to open readonly and then change flags when 
they decide they need to write. Some people comply, others can't believe I 
even asked them to do it.

> Historically, I know, that -w wa is triggered by the open(2) flags
> rather than actual modifications because "[t]he read & write syscalls
> are omitted from this set since they would overwhelm the logs."  Reading
> this again now, it looks a little specious as it seems quite easy to
> overwhelm the logs anyway.
> 
> Is there any reason why a file watcher should not use the fsnotify
> FS_ACCESS/MODIFY/ATTRIB masks before I go haring off to try to implement
> that?

I don't know the particulars. But for auditing purposes, we'd only want 1 
event no matter how many times they wrote. If the w/r flags could be cleaned up 
to be accurate and not signal just the intent, I think that would be good. 
However, I am sure there are tricky corner cases such as mmapped files that 
also need to be accounted for.

Steve