From mboxrd@z Thu Jan  1 00:00:00 1970
From: pg@aud.list.sabi.co.UK (Peter Grandi)
Subject: Re: peculiar disappearance of most audit rules
Date: Wed, 23 Apr 2014 09:04:45 +0100
Message-ID: <21335.29725.410585.629604@tree.ty.sabi.co.uk>
References: <yf3d2gawp23.fsf@tree.gp.example.com> <1806426.QoIu6KxFX5@x2>
	<21333.33865.378826.157120@tree.ty.sabi.co.uk>
	<21334.54971.174073.755376@tree.ty.sabi.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <linux-audit-bounces@redhat.com>
Received: from mx1.redhat.com (ext-mx16.extmail.prod.ext.phx2.redhat.com
	[10.5.110.21])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id s3N88ocV013308
	for <linux-audit@redhat.com>; Wed, 23 Apr 2014 04:08:50 -0400
Received: from honeysuckle.london.02.net (honeysuckle.london.02.net
	[87.194.255.144])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3N88mqK012464
	for <linux-audit@redhat.com>; Wed, 23 Apr 2014 04:08:48 -0400
Received: from ty.sabi.co.UK (94.192.123.224) by honeysuckle.london.02.net
	(8.5.140) id 5266D90A06556E10 for linux-audit@redhat.com;
	Wed, 23 Apr 2014 09:14:50 +0100
Received: from from [127.0.0.1] (helo=tree.ty.sabi.co.uk)
	by ty.sabi.co.UK with esmtp(Exim 4.76 #1) id 1WcsAf-0005aq-I6
	for <linux-audit@redhat.com>; Wed, 23 Apr 2014 09:04:45 +0100
In-Reply-To: <21334.54971.174073.755376@tree.ty.sabi.co.uk>
List-Unsubscribe: <https://www.redhat.com/mailman/options/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/linux-audit>
List-Post: <mailto:linux-audit@redhat.com>
List-Help: <mailto:linux-audit-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/linux-audit>,
	<mailto:linux-audit-request@redhat.com?subject=subscribe>
Sender: linux-audit-bounces@redhat.com
Errors-To: linux-audit-bounces@redhat.com
To: Linux audit <linux-audit@redhat.com>
List-Id: linux-audit@redhat.com

[ ... ]

> Thus I have come up with a potential explanation:

>   * The 'audit' module does not identify the watched file and
>     directory by (device,ino) but by a pointer to an inode table
>     entry, a bit like a filesystem module would.

I had a look at the code and it seems it relies on 'inotify' and
the code does get pointers at the relevant in-memory inode
descriptors.

>   * During treewalks a lot of inodes get cached in the in-memory
>     inode table.
>   * This creates pressure on the inode tables and thus the least
>     used (in some sense) inodes get evicted, and this includes
>     those for the "disappearing directories".
>   * When these least used inodes are evicted the 'audit' module
>     sees it as if it was a removal of the inode.

To corroborate this I have been running:

  while true
  do
    for D in $(< audit-names.txt)
    do (cd "$D" && exec sleep 3001)&
    done
    sleep 3001
  done

Which has the effect of marking the relevant directories as the
active current directories of each 'sleep' process, and none of
those directories were "disappeared" from the 'audit' active
rules list.

The 'inotify' code has a comment that claims:

> * inode: Pinned so long as the inode is associated with a watch, from
> * inotify_add_watch() to the final put_inotify_watch().

They use 'igrab'/'iput', and 'audit_tree.c' and 'audit_watch.c'
uses them, so I wonder what is missing.