I've been working with Freeradius for some time now, and for some reason whenever I tried to configure huntgroups, a segfault occurred. Recently I got back to work on it and got around to pushing the unstripped version through gdb, as well as adding an insane number of extra DEBUG2 statements through the code until I found the exact point where it broke.
This error occurs when the calling IP address matches an entry in the huntgroups, regardless of any other information in the database. I've included the GDB trace from a pristine 0.9.1 debuild below, with sections I believe to be irrelevant snipped for brevity, and sensitive details censored for security's sake. The full (but censored) output can be found at http://hiryuu.systemec.nl/~shadur/radius/gdblog.txt . GNU gdb 2002-04-01-cvs Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-linux"... (gdb) run Starting program: /usr/sbin/freeradius -X Starting - reading configuration files ... reread_config: reading radiusd.conf Config: including file: /etc/freeradius/proxy.conf Config: including file: /etc/freeradius/clients.conf Config: including file: /etc/freeradius/snmp.conf Config: including file: /etc/freeradius/sql.conf {reading lots of config entries} Module: Loaded preprocess preprocess: huntgroups = "/etc/freeradius/huntgroups" preprocess: hints = "/etc/freeradius/hints" preprocess: with_ascend_hack = no preprocess: ascend_channels_per_line = 23 preprocess: with_ntdomain_hack = no preprocess: with_specialix_jetstream_hack = no preprocess: with_cisco_vsa_hack = no Module: Instantiated preprocess (preprocess) Module: Loaded realm realm: format = "suffix" realm: delimiter = "@" Module: Instantiated realm (suffix) Module: Loaded SQL sql: driver = "rlm_sql_mysql" sql: server = "<deleted>" sql: port = "" sql: login = "<deleted>" sql: password = "<deleted> sql: radius_db = "radius" sql: acct_table = "radacct" sql: acct_table2 = "radacct" sql: authcheck_table = "radcheck" sql: authreply_table = "radreply" sql: groupcheck_table = "radgroupcheck" sql: groupreply_table = "radgroupreply" sql: usergroup_table = "usergroup" sql: nas_table = "nas" sql: dict_table = "dictionary" sql: sqltrace = no sql: sqltracefile = "/var/log/freeradius/sqltrace.sql" sql: deletestalesessions = yes sql: num_sql_socks = 5 sql: sql_user_name = "%{User-Name}" sql: default_user_profile = "" sql: query_on_not_found = no rlm_sql (sql): Driver rlm_sql_mysql (module rlm_sql_mysql) loaded and linked rlm_sql (sql): Attempting to connect to <deleted>@<deleted>:/radius rlm_sql (sql): starting 0 rlm_sql (sql): Attempting to connect rlm_sql_mysql #0 rlm_sql_mysql: Starting connect to MySQL server for #0 rlm_sql (sql): Connected new DB handle, #0 rlm_sql (sql): starting 1 rlm_sql (sql): Attempting to connect rlm_sql_mysql #1 rlm_sql_mysql: Starting connect to MySQL server for #1 rlm_sql (sql): Connected new DB handle, #1 rlm_sql (sql): starting 2 rlm_sql (sql): Attempting to connect rlm_sql_mysql #2 rlm_sql_mysql: Starting connect to MySQL server for #2 rlm_sql (sql): Connected new DB handle, #2 rlm_sql (sql): starting 3 rlm_sql (sql): Attempting to connect rlm_sql_mysql #3 rlm_sql_mysql: Starting connect to MySQL server for #3 rlm_sql (sql): Connected new DB handle, #3 rlm_sql (sql): starting 4 rlm_sql (sql): Attempting to connect rlm_sql_mysql #4 rlm_sql_mysql: Starting connect to MySQL server for #4 rlm_sql (sql): Connected new DB handle, #4 Module: Instantiated sql (sql) { More snippage } Listening on IP address *, ports 1812/udp and 1813/udp, with proxy on 1814/udp. Ready to process requests. rad_recv: Access-Request packet from host 111.222.333.444:45695, id=118, length=48 User-Name = "testuser" User-Password = "zronk" modcall: entering group authorize [New Thread 16384 (LWP 22237)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 22237)] 0x40440333 in groupcmp (instance=0x0, req=0x0, request=0x811df28, check=0x810a1c8, check_pairs=0x810a1c8, reply_pairs=0x0) at rlm_unix.c:215 215 if (!req->username) { (gdb) (gdb) backtrace #0 0x40440333 in groupcmp (instance=0x0, req=0x0, request=0x811df28, check=0x810a1c8, check_pairs=0x810a1c8, reply_pairs=0x0) at rlm_unix.c:215 #1 0x08050a46 in paircompare (req=0x0, request=0x811df28, check=0x810a1c8, check_pairs=0x810a1c8, reply_pairs=0x0) at valuepair.c:97 #2 0x08050c9a in paircmp (req=0x0, request=0x811df28, check=0x810a1c8, reply=0x0) at valuepair.c:304 #3 0x40295192 in hunt_paircmp (request=0x811df28, check=0x810a1c8) at rlm_preprocess.c:266 #4 0x4029579c in huntgroup_access (huntgroups=0x810a060, request_pairs=0x811df28) at rlm_preprocess.c:534 #5 0x40295b79 in preprocess_authorize (instance=0x8109258, request=0x811de50) at rlm_preprocess.c:725 #6 0x08055a1e in call_modsingle (component=1, sp=0x8109628, request=0x811de50, default_result=6) at modcall.c:198 #7 0x08055b8c in modcall (component=1, c=0x8109628, request=0x811de50) at modcall.c:304 #8 0x08055a6f in call_modgroup (component=1, g=0x8109c70, request=0x811de50, default_result=6) at modcall.c:220 #9 0x08055b40 in modcall (component=1, c=0x8109c70, request=0x811de50) at modcall.c:296 #10 0x08055046 in indexed_modcall (comp=1, idx=0, request=0x811de50) at modules.c:464 #11 0x0805572f in module_authorize (autz_type=0, request=0x811de50) at modules.c:857 #12 0x08052a23 in rad_authenticate (request=0x811de50) at auth.c:500 #13 0x0804dc98 in rad_respond (request=0x811de50, fun=0x80528bc <rad_authenticate>) at radiusd.c:1525 #14 0x0804d8b3 in rad_process (request=0x811de50, dospawn=0) at radiusd.c:1244 #15 0x0804d4fa in main (argc=2, argv=0xbffffe44) at radiusd.c:1020 This happens whenever IP address of the requesting host matches one of the huntgroup names; hunt_paircmp seems to be sending a null pointer as 'REQUEST' struct to paircomp, which passes it to paircompare, which then blithely passes it on to groupcmp, which doesn't check whether it exists before trying to access one of its members, and boom. I'm not sure why groupcmp and paircompare are even called, because it looks like it calls them only after it has already determined that the huntgroup exists as such... Hope this helps. -- Rens Houben | opinions are mine Resident linux guru and sysadmin | if my employers have one Systemec Internet Services. |they'll tell you themselves PGP key at http://swordbreaker.systemec.nl/~shadur/shadur.key.asc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
