[Aide] manual.html, Understanding Aide rule matching

[Virolainen Pablo]

On Sun, 11 Dec 2005, Marc Haber wrote:

> On Thu, Dec 08, 2005 at 11:44:05AM +0200, Virolainen Pablo wrote:
>> If we have rules "/usr/" and "/usr/local/", "/usr/local/" is deeper
>> match.
>> Rules are placed to selection tree. If we have rule "/usr/local/[bB]*" it
>> will create tree
>> ("/",("/usr/",("/usr/local/",(),"/usr/local/[bB]*",(),()),(),(),()),(),(),())
>
> I do not quite understand that notation. If I see correctly, this is a
> tree of _four_ tuples, not a tree of triples that I would expect. Can
> you please explain again?

I might have missed some () somewhere.. (or there might be missing ()..)
(node-name,(children),(sel rules),(equ rules),(neg rules))

>> When we match entry "/usr/local/bin/sshfs", we first enter (in our tree)
>> to /usr -> local -> bin (and because we don't have bin dir in /usr/local,
>> we'll stay to "/usr/local/"). Then we scan rules in that 'directory' to
>> the root untill we find select rule... Manual.html explains this part.
>
> I suspect that you mean this part here:
>
> check_node_for_match(node,filename)
>        if(no deeper match found)
>                check(equals list for this node)
>
>        if(no deeper match found)
>                check(select list for this node)
>
>        check_node_for_match(nodes parent,filename)
>
>        if(this file is about to be added)
>                check(negative select list for this node)
>
>        return (info about whether this file should be added or not and how)
>
> This is not even consistent to the terminoloy used in the other parts
> of the docs. I suspect that actually this is meant:
>
> check_node_for_match(node,filename)
>        if(no deeper match found)
>                check(equals list for this node)
>
>        if(no deeper match found)
>                check(regular list for this node)
>
>        check_node_for_match(nodes parent,filename)
>
>        if(this file is about to be added)
>                check(negative list for this node)
>
>        return (info about whether this file should be added or not and how)


Call check_node_for_match, with as deep match as possible for the 
filename. (this is easy, because when file are read from the disk by 
following the tree, starting with "/" node. Or one can use 
get_seltree_node). So this might be a bit better pseudo-code.

check_node_for_match(node,filename,first_time)
         if (first_time)
 		check(equals list for this node)

         check(regular list for this node)

         check_node_for_match(nodes parent,filename,false)

         if(this file is about to be added)
                 check(negative list for this node)

         return (info about whether this file should be added or not and how)

> I have the impression that this is simplified too much.
>
>  (a) I don't see the equals list and the regular list being processed
>      differently. Both seem to be handled exactly the same, but
>      probably the equals list takes precedence.
>  (b) I do not understand the recursion here. In my understanding, the
>      "no deeper match" pseudocode is the actual recursion, moving from the
>      root down towards the leaves. I'd like to have this pseudocode
>      explained in more detail.
>  (c) the explictly recursive check_node_for_match call does seem to go
>      in the wrong direction.
>  (d) What's the initial call to enter into the recursion scheme?
>      check_node_for_match("$ROOT_NODE", $FILENAME) for each file in the
>      file system?
(a) = rules are compared only first time. Recursion goes down to root "/" 
node.
Like the source code says
   /* Now let's check the ancestors */
   retval=check_node_for_match(node->parent,text,retval,attr);

(b) I assume that "no deeper match" is derived from idea we (I and Rami) 
had  (1998?) while hacking with aide.

(c) It's just fine.

(d) Well, one might think that our tree is like directory tree, and first 
we chdir to correct subdir. (correct  dir == the deepest match).

> Frankly, to me the pseudocode doesn't make any sense at all. I have
> tried for an hour now to write more verbose pseudocode which might
> explain the operation better, but have failed miserably. Hence, my cry
> for help.
>
>> It's just speed optimisation. '=' rules are not compared when we
>> recursivly go down to root dir/node in our tree. Remember that regexp
>> compare can be quite slow -> so we have tried to minimise the number of
>> comparision.
>
> This is not reflected by the pseudocode, and it is neither mentioned
> nor explained in manual and/or man page.

Yep. This is a documentation problem.

Duke NEMO / C.O.M.A
alias pablo the pallo virolainen