Full_Name: Lukas K. Version: 2.4.44+dfsg-5+deb9u1 OS: Debian Stretch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:7c7:2100:130:b9b5:f8df:7b98:8c2e) During initialization, libldap sets custom gnutls mutex functions: https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/libldap/tls_g.c;h=adcb6be04076a91d3a0bf94cf8357f4e51f5b9da;hb=HEAD#l113 PAM uses libldap via dlopen and unloads it when it's done, but openldap doesn't undo gnutls_global_set_mutex, so any further calls to locking functions inside openldap will segfault since these function pointers now point to nowhere since openldap is unloaded. I encountered this issue in cups since cups uses gnutls itself for the web interface and segfaults when it uses gnutls after libldap.
On Mon, Jan 15, 2018 at 07:33:52PM +0000, lukas@selfnet.de wrote: >During initialization, libldap sets custom gnutls mutex functions: >https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/libldap/tls_g.c;h=adcb6be04076a91d3a0bf94cf8357f4e51f5b9da;hb=HEAD#l113 > >PAM uses libldap via dlopen and unloads it when it's done, but openldap doesn't >undo gnutls_global_set_mutex, so any further calls to locking functions inside >openldap will segfault since these function pointers now point to nowhere since >openldap is unloaded. > >I encountered this issue in cups since cups uses gnutls itself for the web >interface and segfaults when it uses gnutls after libldap. Thanks for this report. This is not the first issue caused by our usage of the custom mutex functions; see also <https://bugs.debian.org/803197>. Removing the custom mutex functions and (for sufficiently recent GnuTLS) the calls to gnutls_global_{,de}init() looks like a more and more attractive solution. I am not aware of anyone using OpenLDAP with GnuTLS on a platform for which GnuTLS lacks built-in mutex functions...
ryan@nardis.ca wrote: > On Mon, Jan 15, 2018 at 07:33:52PM +0000, lukas@selfnet.de wrote: >> During initialization, libldap sets custom gnutls mutex functions: >> https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/libldap/tls_g.c;h=adcb6be04076a91d3a0bf94cf8357f4e51f5b9da;hb=HEAD#l113 >> >> PAM uses libldap via dlopen and unloads it when it's done, but openldap doesn't >> undo gnutls_global_set_mutex, so any further calls to locking functions inside >> openldap will segfault since these function pointers now point to nowhere since >> openldap is unloaded. >> >> I encountered this issue in cups since cups uses gnutls itself for the web >> interface and segfaults when it uses gnutls after libldap. > > Thanks for this report. > > This is not the first issue caused by our usage of the custom mutex > functions; see also <https://bugs.debian.org/803197>. > > Removing the custom mutex functions and (for sufficiently recent GnuTLS) > the calls to gnutls_global_{,de}init() looks like a more and more > attractive solution. I am not aware of anyone using OpenLDAP with GnuTLS > on a platform for which GnuTLS lacks built-in mutex functions... PAM should be using nss-pam-ldapd, not calling libldap directly. This is an architectural flaw in both GnuTLS and PAM, not an OpenLDAP bug. This ITS is invalid. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
> Removing the custom mutex functions and (for sufficiently recent GnuTLS) > the calls to gnutls_global_{,de}init() looks like a more and more > attractive solution. I am not aware of anyone using OpenLDAP with GnuTLS > on a platform for which GnuTLS lacks built-in mutex functions... Just for the record: I recompiled libldap with the call to gnutls_global_set_mutex removed and cups doesn't segfault anymore.
> PAM should be using nss-pam-ldapd, not calling libldap directly. This > is an architectural flaw in both GnuTLS and PAM, not an OpenLDAP bug. > This ITS is invalid. It's called _lib_ldap after all, so are other projects linking against / dlopen()ing libldap doing the wrong thing? Messing with other libraries global state and not undoing it on cleanup isn't exactly what a well-behaved library should do. The gnutls documentation explicitly mentions not to call gnutls_global_set_mutex from libraries: > Do not call this function from a library, or preferably from any > application unless really needed to.
lukas@selfnet.de wrote: >> PAM should be using nss-pam-ldapd, not calling libldap directly. This >> is an architectural flaw in both GnuTLS and PAM, not an OpenLDAP bug. >> This ITS is invalid. > > It's called _lib_ldap after all, so are other projects linking against / > dlopen()ing libldap doing the wrong thing? PAM should not be polluting the application namespace with libraries that the application may itself be using. The same type of problems arise if e.g. the application uses Kerberos and PAM also uses Kerberos, and the application and PAM want to use different configurations. The only correct way for a PAM module to work is to never expose its underlying libraries to the calling application. This is not an OpenLDAP issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
not ours
changed notes changed state Open to Closed