Re: peculiar disappearance of most audit rules

[Steve Grubb <sgrubb@redhat.com>]

On Tuesday, April 22, 2014 09:53:15 PM Peter Grandi wrote:
> >> 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,

I don't know if that is in fact what happens. But if it is, I would agree with 
your conclusion.

-Steve


> 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.