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: Tue, 22 Apr 2014 21:53:15 +0100 Message-ID: <21334.54971.174073.755376@tree.ty.sabi.co.uk> References: <1806426.QoIu6KxFX5@x2> <21333.33865.378826.157120@tree.ty.sabi.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx16.extmail.prod.ext.phx2.redhat.com [10.5.110.21]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3MKrQNC026434 for ; Tue, 22 Apr 2014 16:53:27 -0400 Received: from anakin.london.02.net (anakin.london.02.net [87.194.255.134]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3MKrOLW022336 for ; Tue, 22 Apr 2014 16:53:25 -0400 Received: from ty.sabi.co.UK (94.192.123.224) by anakin.london.02.net (8.5.140) id 51DAA728051CBEA6 for linux-audit@redhat.com; Tue, 22 Apr 2014 21:53:26 +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 1Wchgp-0008N3-LG for ; Tue, 22 Apr 2014 21:53:15 +0100 In-Reply-To: <21333.33865.378826.157120@tree.ty.sabi.co.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Linux audit List-Id: linux-audit@redhat.com >> I don't know what is managing your system, but its probably >> deleting paths. > I am the sole user (as far as I know...) of both systems, [ > ... ] None of the "disappeared" paths seems to have been > modified in any way. [ ... ] Anyhow, I have now recorded the > inos of the watched directories, and I shall also run > 'inotifywait -m /' to catch if possible any changes in '/opt' > and '/boot'. I have done this and this morning during 'mlocate' treewalking some of the usual paths disappeared; I verified the inos and the 'inotify' output and no inos changed nor any of the watched directories changed. Since the list of directories that *do not* disappear is usually: LIST_RULES: exit,always dir=/bin (0x4) perm=wa key=pkg-s LIST_RULES: exit,always dir=/etc (0x4) perm=wa key=pkg-s LIST_RULES: exit,always dir=/lib (0x4) perm=wa key=pkg-s LIST_RULES: exit,always dir=/usr (0x4) perm=wa key=pkg-s LIST_RULES: exit,always dir=/fs/sozan/loc (0xd) perm=wa key=pkg-l LIST_RULES: exit,always dir=/fs/sozan/com (0xd) perm=wa key=pkg-l and those that disappear tend to be far less frequently used directories like '/boot', '/opt', '/lib32'. Rereading this: >> [ ... ] device and inode information. This is, technically, >> what your watch is on. If the inode disappears, then the rule >> is ejected. Rules can survive across renames but not deletions. it appears that I misread earlier: this says "inode", not "inum". Also it says "inode disappears", which is not necessarily always because the on-disk inode is deleted. 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. * 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. If the above is the right explanation it is a pretty big deal, because it means that a way to disable many/most 'audit' watches on files is to create and access a lot of inodes, which is pretty easy to do.