[Aide] manual.html, Understanding Aide rule matching

[Marc Haber]

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?


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

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?

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.

> > I hope that I will finally understand what's going on, and then could
> > help in improving the documentation.
> 
> Improved documentation is needed.

I have done some work on the man page and on the manual, but cannot
publish that because I still fail to understand the rule matching
pseudocode.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835