Skip to contentSkip to conversation

path watcher

DISCUSSION John Haxby 2 participants 2 messages Aug 22, 2014 – Sep 12, 2014

lore
Share & tools
lore

John Haxby

author
#0 lore raw

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

#1 lore raw

Hello,

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

Quoted 3 lines · John Haxby

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.

Quoted 4 lines

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.

Quoted 9 lines

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