[python-ldap] Interesting Django, RHEL, openldap, python-ldap, oracle 19c client problem

[Stephen J. Butler]

You can see in the stack trace the web Django python-ldap has somehow
linked Oracle libraries for LDAP and not OpenLDAP:

0x00007f217ea832b1 in gslcctp_PutControls () from
*/apps/oracle/product/19.0.0/client_1/lib/libclntsh.so
<http://libclntsh.so/>.11.1*
(gdb) backtrace
#0  0x00007f217ea832b1 in gslcctp_PutControls () from
*/apps/oracle/product/19.0.0/client_1/lib/libclntsh.so
<http://libclntsh.so/>.11.1*
#1  0x00007f217ea9a1b0 in gslcsa_SaslBind () from
*/apps/oracle/product/19.0.0/client_1/lib/libclntsh.so
<http://libclntsh.so/>.11.1*
#2  0x00007f217ea7b220 in ldap_sasl_bind () from
*/apps/oracle/product/19.0.0/client_1/lib/libclntsh.so
<http://libclntsh.so/>.11.1*

Did you set some custom LD_LIBRARY_PATH in your webserver or process that
runs web Django that isn't present when you're using manage?


On Fri, May 6, 2022 at 11:28 AM Lance Ellinghaus via python-ldap <
python-ldap at python.org> wrote:

> I am having a very interesting problem with python-ldap, Django, and RHEL.
> I am hoping someone can help me.
>
> I am running RHEL 7 with SELinux turned on, but in advisory mode only.
> I am running the Redhat provided httpd server version 2.4.6-97.el7_9.2
> I am running mod_wsgi compiled by me version 4.9.0
> There are 2 WSGI instances running on the httpd server. They are both in
> Daemon mode. One is 1 process/3 threads, the other is 2 processes/3 threads
> each.
> Running Python 3.9.0 compiled by myself. The Python 3.9.0 has its own copy
> of openssl and openldap and don't use the system provided ones.
> Running openssl version 1.1.1g and openldap version 2.6.1 with python-ldap
> version 3.4.0.
> Running Django version 3.2.9
> Running python-ldapdb 1.5.2
> Django is accessing Oracle 19c binaries as well.
> I have multiple DATABASE entries, 3x oracle and 1x ldap. Django is
> configured to use Oracle for the main repository.
>
>
> When running ./manage shell, I can use python-ldap without any issues.
> Pull data, etc. It all works well.
> When running from a Django view using the same calls, I get a segfault
> when python-ldap performs the bind_s() call.
>
> Here is the top of the stack trace for the segfault:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7f216ba42700 (LWP 26161)]
> 0x00007f217ea832b1 in gslcctp_PutControls () from
> /apps/oracle/product/19.0.0/client_1/lib/libclntsh.so.11.1
> (gdb) backtrace
> #0  0x00007f217ea832b1 in gslcctp_PutControls () from
> /apps/oracle/product/19.0.0/client_1/lib/libclntsh.so.11.1
> #1  0x00007f217ea9a1b0 in gslcsa_SaslBind () from
> /apps/oracle/product/19.0.0/client_1/lib/libclntsh.so.11.1
> #2  0x00007f217ea7b220 in ldap_sasl_bind () from
> /apps/oracle/product/19.0.0/client_1/lib/libclntsh.so.11.1
> #3  0x00007f216e23d6f9 in l_ldap_simple_bind (self=0x7f212a147cf0,
> args=<optimized out>) at Modules/LDAPObject.c:564
> #4  0x00007f2181c56acf in cfunction_call (func=0x7f216a2c1c20,
> args=<optimized out>, kwargs=<optimized out>)
>     at Objects/methodobject.c:546
> #5  0x00007f2181c0d282 in _PyObject_Call (tstate=0x7f215c00a090,
> callable=0x7f216a2c1c20, args=0x7f2169f92900,
>     kwargs=<optimized out>) at Objects/call.c:280
> #6  0x00007f2181c0d36f in PyObject_Call (callable=<optimized out>,
> args=<optimized out>, kwargs=<optimized out>)
>     at Objects/call.c:292
> #7  0x00007f2181bc1a53 in do_call_core (kwdict=0x7f212a1502c0,
> callargs=0x7f2169f92900, func=0x7f216a2c1c20, tstate=0x7f215c00a090)
>     at Python/ceval.c:5092
>
>
> Here is the basic code that I am running. I had to pull this out and strip
> off a lot before and after:
>
> ldap_conn = ldap.initialize('ldap://%s:%d' % (url,port))
> ldap_conn.set_option(ldap.OPT_REFERRALS, 0)
> ldap_conn.set_option(ldap.OPT_PROTOCOL_VERSION, 3)
> ldap_conn.bind_s(bind_u, pind_p)
>
> _______________________________________________
> python-ldap mailing list
> python-ldap at python.org
> https://mail.python.org/mailman/listinfo/python-ldap
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/python-ldap/attachments/20220506/01d6bb6e/attachment-0001.html>