Re: (ITS#8799) slaptest fails to properly convert chain configuration
by ondra＠mistotebe.net
On Mon, Jan 22, 2018 at 09:59:21PM +0000, quanah(a)openldap.org wrote:
> The process for converting a slapd configuration to cn=config making use of
> slapo-chain at a global level is seriously broken.
It's not as bad, just a little bit broken:
> This can be trivially illustrated by using the slapd.conf generated by test032.
>
> After doing conversion, the resulting cn=config database has *two* ldap backends
> defined:
>
> dn: olcDatabase={-1}frontend,cn=config
> dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
> dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf
This is the catchall database used to handle referrals that are not
handled by any other database you configure by hand. It collects all the
chain-* settings that appear before the first chain-uri.
> dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf
>
> The first instance ({0}ldap,...) isn't even valid. If you remove the entire
> chain configuration from this database, and then attempt to import it, you get
> the following:
Yeah that is a problem.
> ldap_add: Object class violation (65)
>
> This is because the first instance ({0}) is *missing* the required olcDbURI
> attribute. In addition, it generates completely bogus attribute values (See
> ITS#8693)
Maybe we just need to inherit objectclass: olcLdapDatabase somehow in
olcChainOverlay and keep these settings in the overlay entry, or specify
a bogus URI to be configured there. Whatever is most useable and still
allows for seamless expansion.
> The *second* generated LDAP backend database is what is correct.
>
> Here's the LDIF for the incorrect database:
>
> [...]
>
> Here's the LDIF for the *correct* database:
>
> [...]
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
5 years, 8 months
(ITS#8799) slaptest fails to properly convert chain configuration
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.45
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
The process for converting a slapd configuration to cn=config making use of
slapo-chain at a global level is seriously broken.
This can be trivially illustrated by using the slapd.conf generated by test032.
After doing conversion, the resulting cn=config database has *two* ldap backends
defined:
dn: olcDatabase={-1}frontend,cn=config
dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf
dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=conf
The first instance ({0}ldap,...) isn't even valid. If you remove the entire
chain configuration from this database, and then attempt to import it, you get
the following:
ldapadd -H ldap:/// -D cn=config -w secret -f ./olcOverlay\=\{0\}chain.ldif
adding new entry "olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config"
ldapadd -H ldap:/// -D cn=config -w secret -f ./olcDatabase\=\{0\}ldap.ldif
adding new entry "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config"
ldap_add: Object class violation (65)
This is because the first instance ({0}) is *missing* the required olcDbURI
attribute. In addition, it generates completely bogus attribute values (See
ITS#8693)
The *second* generated LDAP backend database is what is correct.
Here's the LDIF for the incorrect database:
dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {0}ldap
olcDbStartTLS: none starttls=no
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
Here's the LDIF for the *correct* database:
dn: olcDatabase={1}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: {1}ldap
olcDbURI: "ldap://localhost:9012"
olcDbStartTLS: none starttls=no
olcDbIDAssertBind: mode=self flags=non-prescriptive,proxy-authz-non-critical
bindmethod=simple timeout=0 network-timeout=0 binddn="cn=manager,dc=exampl
e,dc=com" credentials="secret" keepalive=0:0:0
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE
olcDbOnErr: continue
olcDbKeepalive: 0:0:0
However, even in the case of the *correct* LDIF, the bogus olcDbStartTLS
attribute is defined (Again, ITS#8693)
This is the slapd.conf used to convert:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/openldap.schema
include /usr/local/etc/openldap/schema/nis.schema
pidfile /tmp/slapd.1.pid
argsfile /tmp/slapd.1.args
modulepath /usr/local/libexec/openldap
moduleload back_mdb.la
moduleload back_ldap.la
moduleload back_monitor.la
overlay chain
chain-uri ldap://localhost:9012/
chain-idassert-bind bindmethod=simple
binddn="cn=Manager,dc=example,dc=com"
credentials=secret
mode=self
flags=non-prescriptive
database mdb
suffix "dc=example,dc=com"
rootdn "cn=Manager,dc=example,dc=com"
rootpw secret
directory /tmp/db.1.a
index objectClass eq
index cn,sn,uid pres,eq,sub
database monitor
5 years, 8 months
Re: (ITS#8797) improper use of gnutls causes segfault
by hyc＠symas.com
lukas(a)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/
5 years, 8 months
Re: (ITS#8797) improper use of gnutls causes segfault
by lukas＠selfnet.de
> 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.
5 years, 8 months
Re: (ITS#8797) improper use of gnutls causes segfault
by lukas＠selfnet.de
> 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.
5 years, 8 months
Re: (ITS#8797) improper use of gnutls causes segfault
by hyc＠symas.com
ryan(a)nardis.ca wrote:
> On Mon, Jan 15, 2018 at 07:33:52PM +0000, lukas(a)selfnet.de wrote:
>> During initialization, libldap sets custom gnutls mutex functions:
>> https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=librari...
>>
>> 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/
5 years, 8 months
Re: (ITS#8797) improper use of gnutls causes segfault
by ryan＠nardis.ca
On Mon, Jan 15, 2018 at 07:33:52PM +0000, lukas(a)selfnet.de wrote:
>During initialization, libldap sets custom gnutls mutex functions:
>https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=librari...
>
>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...
5 years, 8 months
