Bug 128364 - FreeRadius segfaults when LDAP used
FreeRadius segfaults when LDAP used
Status: CLOSED DUPLICATE of bug 111492
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: freeradius (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Thomas Woerner
Depends On:
  Show dependency treegraph
Reported: 2004-07-22 01:25 EDT by Tarun Bhushan
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:04:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output/configuration as described in bug report (13.38 KB, text/plain)
2004-07-22 01:32 EDT, Tarun Bhushan
no flags Details

  None (edit)
Description Tarun Bhushan 2004-07-22 01:25:24 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040626 Firefox/0.9.1

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):

How reproducible:

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

Additional info:

Attached text file.
Comment 1 Tarun Bhushan 2004-07-22 01:32:28 EDT
Created attachment 102129 [details]
Output/configuration as described in bug report
Comment 2 Tarun Bhushan 2004-08-10 03:59:34 EDT
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, 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()
radius_xlat:  'dc=dimmy,dc=someplace,dc=com'
radius_xlat:  '(cn=<removed>)'
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: ldap2.dimmy.someplace.com
ldap_new_socket: 6
ldap_prepare_socket: 6
ldap_connect_to_host: Trying
ldap_connect_timeout: fd: 6 tm: 5 async: 0
ldap_ndelay_on: 6
ldap_is_sock_ready: 6
ldap_ndelay_off: 6
ldap_int_sasl_open: host=ldap2.dimmy.someplace.com
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
Segmentation fault
Comment 3 Tarun Bhushan 2004-08-17 03:56:32 EDT
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.
Comment 4 Thomas Woerner 2004-08-17 04:55:56 EDT

*** This bug has been marked as a duplicate of 111492 ***
Comment 5 Red Hat Bugzilla 2006-02-21 14:04:35 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.