FR 2.0.3 gives duplicate NULL realm error

[John Horne]

On Tue, 2008-04-08 at 10:14 +0100, John Horne wrote:
> On Tue, 2008-04-08 at 08:18 +0200, Alan DeKok wrote:
> > John Horne wrote:
> > > It seems that radiusd doesn't like the NULL realm after the DEFAULT. I
> > > swapped these two around, and radiusd started up fine.
> > 
> >   ?  I can start up the server fine with those realms, in any order.
> > 
> Yes, with 2.0.2 I had the NULL realm in proxy.conf last. However, with
> 2.0.3 I have swapped these around a couple of times now, and it always
> fails (duplicate realm error) if the NULL realm is last and the DEFAULT
> realm is present. If I comment out the DEFAULT realm, although the NULL
> realm is still last, then radiusd starts up. So it seems to be an
> interaction between both the DEFAULT and NULL realms being present.
> 
Okay, I've looked into this a bit further. The Changelog shows that a
change to realms (the 'realm_find' function in realms.c) was made in FR
2.0.2 (which explains why my FR 2.0.1 worked):

        * Fall back to DEFAULT realm if no realm was found.
          Based on a patch from Vincent Magnin.

I found a copy of the patch, and removed it from the 2.0.3 source code.
Starting radiusd then worked regardless of what order the DEFAULT/NULL
realms were in.

The NULL realm is configured as:

       realm NULL {
               auth_pool = local_proxies
       }

If I comment out the 'auth_pool' line, then radiusd starts up (having
put the above patch back in). However, from the code (realms.c, line
1174 onwards) this is probably due to FR treating the NULL realm as an
old-style realm and, hence, allowing it.

I am at this point now stuck. The 'duplicate realm' message occurs
because of the result of 'realm_find' for the NULL realm. However,
realm_find (in realms.c at line 1323) shows:

===========================================================
   REALM *realm_find(const char *name)
   {
           REALM myrealm;
           REALM *realm;

           if (!name) name = "NULL";

           myrealm.name = name;
           realm = rbtree_finddata(realms_byname, &myrealm);
           if (realm) return realm;

           /*
            *      Couldn't find a realm.  Look for DEFAULT.
            */
           myrealm.name = "DEFAULT";
           return rbtree_finddata(realms_byname, &myrealm);
   }
===========================================================

For some reason the NULL realm is not being found (using
rbtree_finddata), and so it then looks for the DEFAULT realm. But we
have already seen the DEFAULT realm.

If I change the code to look for the 'myrealm.name = "DEFAULTx"' realm,
then radiusd starts up okay (or rather there is no error message; it is
possible though that radiusd now thinks it has no NULL realm configured,
although 'radiusd -XC' indicates that it has seen it).

I am not sure that the above code ('realm_find') is correct though. It
changes 'myrealm.name' to DEFAULT, and then returns the
pointer/structure (I assume) of the DEFAULT realm. However, this was
called from line 1174 which is expecting the NULL realm (and has 'name2'
set to that). I don't think just looking for the DEFAULT realm is
enough, it needs to change other variables such as 'name2'. (I may be
completely wrong about all this though!)

If I change the NULL realm in proxy.conf to:

     realm NULL {
     #       auth_pool = local_proxies
             authhost = localhost
     }

I then get from radiusd:

    realm NULL {
    /etc/raddb/proxy.conf[107]: No shared secret supplied for realm:
DEFAULT
    } # realm NULL

Which seems to indicate that the DEFAULT and NULL realms are indeed
getting mixed up. The 'DEFAULT' name in the error message comes from the
'r' structure (which it got from within 'realm_find' when it couldn't
find the NULL realm); the 'NULL' parts come from the variable 'name2'.


This is as far as I have got. The 'rbtree_finddata' code (in
src/lib/rbtree.c, line 494) starts to get a bit too convoluted for me,
but as to why the NULL realm is not found seems to be the root of the
'duplicate realm' error.


Regards,

John.

-- 
---------------------------------------------------------------
John Horne, University of Plymouth, UK  Tel: +44 (0)1752 587287
E-mail: John.Horne at plymouth.ac.uk       Fax: +44 (0)1752 233839