Possible Bug in valuepair / rlm_file etc etc.

[Alister Winfield]

I have found a potential bug in the way rlm_file or valuepair does the
xlat of %{var} items. These are supposedly dynamic, being based on a
per-packet replacement. The following example can be done a different
way but its the simplest example I can think of ;-)

Take the following from a users file (X-MyCLI filled in from some db in
an earlier module).

DEFAULT X-MyCLI != "%{Calling-Station-Id}", Auth-Type:="Reject"

The db of valid CLI's might contain.

user	cli
---------------
one	12345
two	54321

If you do two queries that should auth one thats sending: username=one,
callingid=12345; the other username=two, callingid=54321. Only the first
works the second failing because the in memory config for the check will
have changed to read X-MyCLI != 12345 ...!!!

Looking at the code this appears to be due to paircmp expanding the %{}
on the structure passed to it (a potentially bad idea for so many
reasons). 

The best solution, I suspect, is to copy the data sent to paircmp and
work on the copy and not the original. The copy can be done on a
per-pair way and if deemed expensive only for things that need xlat. 

..............................................
In sudo code:


for (check; check->next ; .....

memcpy(&blah, check, sizeof(check));
Do the comparison using blah instead of check.
memcpy(check, &blah, sizeof(check));
...............................................


I don't have a detailed patch yet as I have only done half the work
required to avoid trashing the config but thus far it does fix my case.

PS: Although I have only looked at 1.0.2 this appears to hold true of
the CVS head as well.

Am I missing something here and if not I'll be back soon with a complete
patch (Currently I just save the old check_item and put it back which is
fine in a single thread but not so clever in a threaded system).

--
Alister Winfield