From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Description of problem:
FreeRadius segfaults when LDAP is used for authorisation. I tried this
with the FreeRadius released with base RHEL3, as well as the update
version freeradius-0.9.3-1. The problem appears to be similar to bug
126507, reported for FreeRadius on Fedora Core 2, but there are
differences. In the latter bug report, OpenLDAP was reportedly using
SASL2, while FreeRadius' rlm_ldap was using SASL. However, on RHEL3,
an ldd on libldap.so and rlm_ldap.so shows that they both appear to be
linked to libsasl.so.7 (both outputs attached separately) - this is
what is different to the report for FC2. However, the symptoms are the
I even compiled freeradius-1.0.0-pre3 by using the latest Rawhide SRPM
for FC2 (where this problem is reportedly fixed) just to make sure,
with the same segfault result.
The output from running the daemon with radiusd -X is attached
separately, as is an entry for the LDAP part of radiusd.conf.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Steps to Reproduce:
1. Install FreeRADIUS.
2. Configure FreeRADIUS to use LDAP as a backend.
3. Start FreeRADIUS as radiusd -X.
4. Authenticate client using FreeRADIUS.
Actual Results: FreeRadius segfaults
Expected Results: Authentication and authorisation completes and the
process keeps running
Attached text file.
Created attachment 102129 [details]
Output/configuration as described in bug report
This does appear to be TLS related. When used without TLS (port 389,
start_tls=no,tls_mode=no), it works perfectly. When TLS is used (port
636, start_tls=no,tls_mode=no), it seg faults.
I just tried it on a RHEL3ES machine with all available patch/updates
installed, and did a "rpmbuild -ba" on the just released FreeRadius
1.0.0, and then installed and configured it, with a result just as
before (which, as I said, I got with the original RHEL3 version of
FreeRadius plus its later official update). An extract of running
radiusd with the -X flag (and ldap_debug=1) is shown below:
Ready to process requests.
rad_recv: Access-Request packet from host 10.20.9.1:16606, id=22,
User-Name = "<removed>"
User-Password = "<removed>"
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
modcall[authorize]: module "preprocess" returns ok for request 0
modcall[authorize]: module "chap" returns noop for request 0
modcall[authorize]: module "mschap" returns noop for request 0
rlm_realm: No '@' in User-Name = "<removed>", looking up realm NULL
rlm_realm: Found realm "NULL"
rlm_realm: Adding Stripped-User-Name = "<removed>"
rlm_realm: Proxying request from user <removed> to realm NULL
rlm_realm: Adding Realm = "NULL"
rlm_realm: Authentication realm is LOCAL.
modcall[authorize]: module "suffix" returns noop for request 0
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module "eap" returns noop for request 0
users: Matched DEFAULT at 10
rlm_ldap: Entering ldap_groupcmp()
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: attempting LDAP reconnection
rlm_ldap: (re)connect to ldap2.dimmy.someplace.com:636, authentication 0
rlm_ldap: setting TLS mode to 1
rlm_ldap: setting TLS CACert File to /etc/raddb/certs/demoCA/root.ca.pem
rlm_ldap: bind as <removed>/<removed> to ldap2.dimmy.someplace.com:636
ldap_connect_to_host: Trying 10.14.5.19:636
ldap_connect_timeout: fd: 6 tm: 5 async: 0
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 1, subject: <removed>, issuer:
TLS certificate verification: depth: 0, subject: <removed>, issuer:
TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server certificate request A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client certificate A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL_connect:SSLv3 read finished A
I determined that the problem is at the the line 845 in tls.c within
the OpenLDAP library libldap. The line is "method->ext_free(alt);".
From OpenLDAP problem 1924
I could see why the problem happens. I have added my comments to a
related issue - bug 111492.
*** This bug has been marked as a duplicate of 111492 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.