Hi, Eric.
I've been involved into development of fanotify-based monitor
for anti-virus software. Alternatively our product uses monitoring
based on redirfs module.
At the moment we provide some functionality based on uid and gid pair
of process that performs file operations. It's assumed by fanotify design
that this information can be extracted from /proc/<pid> entries with pid
provided as a part of fanotify event metadata.
However under some circumstances it seems impossible to extract
any process-related information. The case I'm describing arise when
process has open fds up to the process exit (normal or abnormal).
Process termination causes it to close any opened file descriptors.
Since FAN_CLOSE_WRITE and FAN_CLOSE_NOWRITE are non-blocking
events it's possible that terminating process will completely exit
before scheduler will give control to the fanotify-based monitor. And
thus fanotify-based monitor will be unable to open relevant proc entry.
As a workaround I've already considered solution where uid:gid cached on
file opening. But this still can't be error-proof. I.e. process could
open file
for writing (i.e. redirected stdout) then fork and exit before its
child. In this
situation file will be opened by parent and closed by child. Besides uid:gid
could be different on open and on close. So this way is not suitable.
So, I'm looking for suggestions, pros and cons on how to overcome this
issue by patching kernel. Here is list of ways I think could solve the
problem:
1) Provide uid and gid as a part fanotify_event_metadata received from the
kernel. Seems to be ugly-scaled solution if somebody wants to receive other
process-related information.
2) Introduce FAN_CLOSE_NOWRITE_PERM and FAN_CLOSE_WRITE_PERM
events. Since close return value doesn't make sense, these events could
be named FAN_CLOSE_NOWRITE_BLOCK and FAN_CLOSE_WRITE_BLOCK.
3) Keep process in zombie state until fanotify monitor will reply to all
process-related events. In this way fanotify monitor should guarantee
that it will send replies to all events. This guarantee could be given by
specific fanotify_init flag.
Looking for your opinions, Roman.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
