Alan DeKok wrote:

Paul Bender <[EMAIL PROTECTED]> wrote:

I do not believe I am using TLS (or SSL) to connect to the LDAP server, since I have set start_tls=0 in my ldap module configuration and since freeradius is attempting to connect to the ldap (not the ldaps) port.


  See doc/bugs for details on more detailed bug reporting & information.

  Also, see bugs.freeradius.org

  Alan DeKok.

- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

I think I found it. The problem appears to be that rlm_ldap checks for and links against libsasl, but the OpenLDAP libraries use libsasl2. As a result, when FreeRADIUS runs, it loads both libsasl.so and libsasl2.so. This causes a problem since they contain incompatible versions of sasl_client_new. It appears that with both of them loaded, OpenLDAP ends up calling the sasl_client_new in libsasl.so but it was compiled against the version of sasl_client_new in libsasl2.so. As a result, it segfaults.


Having said that, I cannot figure out why rlm_ldap checks for and links against libsasl. If I stop rlm_ldap from linking against libsasl, everything appears to work. Does anyone know why rlm_ldap needs libsasl?

Anyway, for those that care, here is what I did to find the problem:

I did a backtrace from within gdb, which I have included below (with the password replaced). It has been pointed out in this thread that FreeRADIUS does not segfault when OpenLDAP is compiled without SASL support. Looking at the backtrace, the segfault is happening in sasl_client_new.

Interestingly, based on the line number and arguments for sasl_client_new, OpenLDAP appears to be using the sasl_client_new from SASL 1.5.28 not from SASL 2.1.18. However, based on the line number for ldap_int_sasl_open, OpenLDAP appears to be using the sasl_client_new from SASL2. The agruments for this function change from SASL1 to SASL2. Therefore, if the wrong version of sasl_client_new is being called, then there could be a real problem.

Using 'info shared' within gdb reveals that both libsasl.so.7 and libsasl2.so.2 are loaded and that the memory location for the sasl_client_new in the backtrace is within the address range of libsasl.so.7.

I moved all the libsasl libraries and restarted freeradius. Freeradius would not start because rlm_ldap needed libsasl.so.7. When I look at rlm_ldap, I find that during its configuration, it is checking for libsasl. However, looking at the code, I cannot figure out why it needed libsasl. Therefore, I rebuilt freeradius with the libsasl libraries moved so that rlm_ldap would not find time. Once I installed this version of freeradius, freeradius no longer segfaulted.

----- bt -----

#0 0x00ad361d in sasl_client_new (service=0x44ef79 "ldap", serverFQDN=0x82d5b48 "server.private", prompt_supp=0x82d5b78,
secflags=137190264, pconn=0x44ec40) at client.c:435
#1 0x004304a8 in ldap_int_sasl_open (ld=0x82d56f0, lc=0x82d5ac8, host=0x82d5b48 "server.private") at cyrus.c:476
#2 0x0042abee in ldap_int_open_connection (ld=0x82d56f0, conn=0x82d5ac8, srv=0x82d5a58, async=0) at open.c:348
#3 0x0043ce69 in ldap_new_connection (ld=0x82d56f0, srvlist=0x82d5a58, use_ldsb=1, connect=1, bind=0x0) at request.c:315
#4 0x0042a6a1 in ldap_open_defconn (ld=0x82d56f0) at open.c:32
#5 0x0043c9df in ldap_send_initial_request (ld=0x82d56f0, msgtype=96, dn=0x82cb120 "uid=radiusd,ou=users,dc=private",
ber=0x82d57b0) at request.c:98
#6 0x004328b7 in ldap_sasl_bind (ld=0x82d56f0, dn=0x82cb120 "uid=radiusd,ou=users,dc=private", mechanism=0x0,
cred=0xfef0d9f0, sctrls=0x82d5b78, cctrls=0x82d5b78, msgidp=0xfef0d9ec) at sasl.c:143
#7 0x004332d0 in ldap_simple_bind (ld=0x82d56f0, dn=0x82d5b78 "ȧ«", passwd=0x0) at sbind.c:81
#8 0x0042a565 in ldap_bind (ld=0x82d56f0, dn=0x82d5b78 "ȧ«", passwd=0x82d5b78 "ȧ«", authmethod=128) at bind.c:71
#9 0x0061764d in ldap_connect (instance=0x82d15b8, dn=0x82cb120 "uid=radiusd,ou=users,dc=private",
password=0x82cb148 "****", auth=0, result=0xfef0dac8) at rlm_ldap.c:1675
#10 0x00617d8d in perform_search (instance=0x82d15b8, conn=0x82d1840, search_basedn=0xfef0dc70 "dc=private", scope=2,
filter=0xfef0e070 "(uid=paul)", attrs=0x82d18f8, result=0xfef0db68) at rlm_ldap.c:685
#11 0x0061a369 in ldap_authorize (instance=0x82d15b8, request=0x82d3c10) at rlm_ldap.c:1145
#12 0x08057e24 in modcall (component=1, c=0x82ce528, request=0x82d3c10) at modcall.c:219
#13 0x080580c6 in modcall (component=1, c=0x82cb4e8, request=0x82d3c10) at modcall.c:252
#14 0x080571b4 in indexed_modcall (comp=1, idx=2785, request=0x82d5b78) at modules.c:469
#15 0x08053e15 in rad_authenticate (request=0x82d3c10) at auth.c:552
#16 0x0804c917 in rad_respond (request=0x82d3c10, fun=0x8053d70 <rad_authenticate>) at radiusd.c:1664
#17 0x0804e4d0 in main (argc=2, argv=0xfef10504) at radiusd.c:1452


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to