Logged in as guest
Viewing Software Bugs/6837 Full headers
Major security issue: yes no
Notes: back-ldap (back-config) fixed in HEAD fixed in RE24 Notification:
Date: Thu, 17 Feb 2011 16:06:30 +0000 From: rhafer@suse.de To: openldap-its@OpenLDAP.org Subject: slapd doesn't start anymore after adding olcChainDatabase
Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.243.151) After adding the following LDIF to cn=config (via ldapadd), slapd does not start anymore: ------------------------------------ dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectclass: olcChainConfig dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectclass: olcLDAPConfig objectclass: olcChainDatabase olcDbUri: ldap://ldap.server olcDatbase: {0}ldap ------------------------------------ To add some fun. Everything works as expected if I reorder the "objectClass" Values so that "olcLDAPConfig" appears after "olcChainDatabase". Additionally the error messages I get in the log when slapd fails to start with the above config seem to be completely unrelated: ------ olcRootPW: value #0: <olcRootPW> can only be set when rootdn is under suffix config error processing olcDatabase={0}config,cn=config: <olcRootPW> can only be set when rootdn is under suffix ------ The underlying problem seems to be that, when the "olcLDAPConfig" objectclass appears first slapd seems to choose the wrong ConfigTable for the olcDatabase attribute of the olcChainDatabase object. Instead of using olcDatabaseDummy as defined in back-ldap/chain.c it uses the "normal" ConfigTable and starts up the LDAP Database as if it were in "normal" database, including adding it to the backendDB list. As I configured the chain overlay as a global overlay this back-ldap database is put to the front of the backendDB list leading to problems when initializing the cn=config database itself, because the code assumes that the config database is always the first one, which will than lead to the strange error message above. (... that's how far I got with analyzing the problem, I have no idea yet how to fix it though. Suggestions are welcome.)
Date: Fri, 18 Feb 2011 15:55:26 -0800 From: Howard Chu <hyc@symas.com> To: rhafer@suse.de CC: openldap-its@openldap.org Subject: Re: (ITS#6837) slapd doesn't start anymore after adding olcChainDatabase
rhafer@suse.de wrote: > Full_Name: Ralf Haferkamp > Version: RE24, HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.243.151) > > > After adding the following LDIF to cn=config (via ldapadd), slapd does not start > anymore: > ------------------------------------ > dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectclass: olcChainConfig > > dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config > objectclass: olcLDAPConfig > objectclass: olcChainDatabase > olcDbUri: ldap://ldap.server > olcDatbase: {0}ldap > ------------------------------------ > > To add some fun. Everything works as expected if I reorder the "objectClass" > Values so that "olcLDAPConfig" appears after "olcChainDatabase". > > Additionally the error messages I get in the log when slapd fails to start with > the above config seem to be completely unrelated: > ------ > olcRootPW: value #0:<olcRootPW> can only be set when rootdn is under suffix > config error processing olcDatabase={0}config,cn=config:<olcRootPW> can only be > set when rootdn is under suffix > ------ > > The underlying problem seems to be that, when the "olcLDAPConfig" objectclass > appears first slapd seems to choose the wrong ConfigTable for the olcDatabase > attribute of the olcChainDatabase object. Instead of using olcDatabaseDummy as > defined in back-ldap/chain.c it uses the "normal" ConfigTable and starts up the > LDAP Database as if it were in "normal" database, including adding it to the > backendDB list. As I configured the chain overlay as a global overlay this > back-ldap database is put to the front of the backendDB list leading to problems > when initializing the cn=config database itself, because the code assumes that > the config database is always the first one, which will than lead to the strange > error message above. > > (... that's how far I got with analyzing the problem, I have no idea yet how to > fix it though. Suggestions are welcome.) > The cleanest solution would probably be to make olcChainDatabase structural, copying all of the attributes of olcLDAPConfig into it, and dropping olcLDAPConfig itself from this situation. Too bad changing that now would break existing deployments. I'll look into this some more. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Date: Sat, 19 Feb 2011 01:05:23 +0100 (CET) Subject: Re: (ITS#6837) slapd doesn't start anymore after adding olcChainDatabase From: masarati@aero.polimi.it To: hyc@symas.com Cc: openldap-its@openldap.org
> The cleanest solution would probably be to make olcChainDatabase > structural, > copying all of the attributes of olcLDAPConfig into it, and dropping > olcLDAPConfig itself from this situation. Too bad changing that now would > break existing deployments. From a protocol point of view, olcChainDatabase could be derived from olcLDAPConfig; at this point the two could coexist in existing deployments. back-config could take care of objectClass inheritance while selecting configuration tables. p.
Date: Fri, 18 Feb 2011 16:13:09 -0800 From: Howard Chu <hyc@symas.com> To: masarati@aero.polimi.it CC: openldap-its@openldap.org Subject: Re: (ITS#6837) slapd doesn't start anymore after adding olcChainDatabase
masarati@aero.polimi.it wrote: > >> The cleanest solution would probably be to make olcChainDatabase >> structural, >> copying all of the attributes of olcLDAPConfig into it, and dropping >> olcLDAPConfig itself from this situation. Too bad changing that now would >> break existing deployments. > >> From a protocol point of view, olcChainDatabase could be derived from > olcLDAPConfig; at this point the two could coexist in existing > deployments. back-config could take care of objectClass inheritance while > selecting configuration tables. back-config already uses inheritance to order the objectClasses. But I think it may be happening too late to address this. Still looking, probably a simple fix in that case. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
______________ © Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org
