From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roman Valov Subject: [fanotify] unable to read /proc/ for files closed on process exit. Date: Wed, 16 Jan 2013 18:41:01 +0400 Message-ID: <50F6BBFD.5070600@kaspersky.com> References: <50F42F2D.8050904@kaspersky.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit To: , Return-path: Received: from relay3.kaspersky-labs.com ([91.103.66.246]:16550 "EHLO relay3.kaspersky-labs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751969Ab3APOvO (ORCPT ); Wed, 16 Jan 2013 09:51:14 -0500 Received: from relay3.kaspersky-labs.com (unknown [127.0.0.1]) by mx3.kaspersky-labs.com (Postfix) with ESMTP id B9DC86D696 for ; Wed, 16 Jan 2013 18:41:15 +0400 (MSK) Received: from kas30pipe.localhost (unknown [127.0.0.1]) by mx3.kaspersky-labs.com (Postfix) with ESMTP id 75A9F6D68B for ; Wed, 16 Jan 2013 18:41:15 +0400 (MSK) In-Reply-To: <50F42F2D.8050904@kaspersky.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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/ 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.