[Aide] Explain equals selection lines?
Robert Griffin
rmg at ua.edu
Fri May 18 19:29:16 EEST 2007
Hi,
I'm new to aide, and trying to understand precisely what can be
specified by each line in aide.conf. I'm currently having trouble
figuring out the intended nature of equals selection lines. So far I
understand that:
1. among equals and regular lines that would match a given file,
a. the deepest (most specific) match wins, but
b. an equals match beats a regular match at the same depth, and
c. an earlier-listed match beats a later-listed match
of the same depth and type.
2. negative selection lines at any depth may override the above.
Please correct me if this is not an accurate summary. Now on to my
confusion:
The manual at http://www.cs.tut.fi/~rammer/aide/manual.html (version
0.13) says:
> =/etc matches not only /etc but all the files under it.
>
> So =/etc$ R+a would be the correct form.
All right, so the stuff after = is a regexp with implicit ^ in front.
But then in gen_list.c (v 1.30, from aide 0.13.1):
> /* if no deeper match found */
> if(!((retval&8)==8)&&!((retval&4)==4)){
> if(!check_list_for_match(node->equ_rx_lst,text,attr)){
> /*
> Zhi Wen Wong added this line to fix bug that equ not work for
> compare
> if we do "=/bin", we should only check /bin
> so, /bin/bash or /bin/something should return 0 as neg
> */
> if(!check_list_for_equal(node->equ_rx_lst,text,attr))
> retval|=(2|4);
> };
> };
The block comment is nearly useless, but if I understand the code
correctly, an equals line has to match not only as a regexp (!
check_list_for_match), but also as a plain string comparison (!
check_list_for_equal)... With a dollar sign or any other regexp
metacharacters in the rule, how is that string comparison ever going
to succeed? And, without a dollar sign, how would the string
comparison succeed in selecting deeper files?
Also, the manual says in pseudocode:
> check_node_for_match(node,filename,first_time)
> if (first_time)
> check(equals list for this node)
and in text:
> As it can also be seen, equals selection lines are only checked in
> the first recursion step, thus providing some kind of speed
> optimization by reducing the number of necessary regular expression
> evaluations, which is a quite expensive operation.
But, there is nothing in the actual code that skips the equals check
upon recursive invocation of check_node_for_match. Can anyone explain
which is the intended behavior?
Thanks,
Robert Griffin
Unix Systems Administrator
OIT, Enterprise Technology
The University of Alabama
More information about the Aide
mailing list