Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Hi, here is an openldap issue. This new issue is related to CVE-2007-6698 but was only published 4 days ago: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5358 ==================================== Date: Thu, 7 Feb 2008 11:01:39 GMT From: rhafer@suse.de To: openldap-its@OpenLDAP.org Subject: Modrdn operation with NOOP control crashes BDB backend Full_Name: Ralf Haferkamp Version: HEAD, RE23, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.185.54) This is basically the same issue as ITS#4925. The issue is also apparent in the MODRDN operation: ldapmodrdn -x -h :389 -D <dn> -w <pw> -e \noop ou=test,dc=my-domain,dc=com ou=test2 causes the server to crash. Fix is similar to the ITS#4925 fix. ========================================= This has been fixed the 7th.
Fix: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/back-bdb/modrdn.c.diff?r1=1.197&r2=1.198&f=h
ldap-bugs please advise.
(In reply to comment #2) > ldap-bugs please advise. > *ping*
2.3.41 InCVS, contains the fix already. Please do the usual FEATURES="test" and report any issues
Markus, will there also be an update to the 2.4 branch? Arches, please test and mark stable: =net-nds/openldap-2.3.41 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 release s390 sh sparc x86"
ppc64 done
x86 stable
(In reply to comment #4) > 2.3.41 InCVS, contains the fix already. > > Please do the usual FEATURES="test" and report any issues Er, that's the usual FEATURES="userpriv test" or you'll see this: >>>>> Starting test007-replication ... running defines.sh Starting master slapd on TCP/IP port 9011... Starting slave slapd on TCP/IP port 9012... Using ldapsearch to check that master slapd is running... Using ldapsearch to check that slave slapd is running... Starting slurpd... Using ldapadd to populate the master directory... Waiting 15 seconds for slurpd to send changes... Using ldapmodify to modify master directory... Waiting 15 seconds for slurpd to send changes... Stopping the slave... Waiting 5 seconds for slave slapd to die... Applying more changes to the master slapd... Stopping slurpd... Waiting 5 seconds for slurpd to die... Applying more changes to the master slapd... Restarting slave slapd on TCP/IP port 9012... Using ldapsearch to check that slave slapd is running... Restarting slurpd... Waiting 15 seconds for slurpd to send changes... Try updating the slave slapd... Waiting 15 seconds for slurpd to send changes... Using ldapsearch to read all the entries from the master... Using ldapsearch to read all the entries from the slave... Filtering master results... ./scripts/acfilter.sh: line 18: 23375 Hangup $SLURPD -f $CONF1 -d ${SLURPD_DEBUG-5} -t $DBDIR1B >> $SLURPLOG 2>&1 Filtering slave results... Comparing retrieved entries from master and slave... test failed - master and slave databases differ >>>>> ./scripts/test007-replication failed (exit 1) make[1]: *** [bdb-yes] Error 1 make[1]: Leaving directory `/dev/shm/portage/net-nds/openldap-2.3.41/work/openldap-2.3.41/tests' make: *** [tests] Error 2
Oh wait, that test fails with userpriv as well. That appears to be a regression, and unfortunately the test suite bails out at that point.
alpha/ia64/sparc stable
ppc stable
amd64 stable
hppa/ldap-bugs: any news here wrt comment #8 and 9?
I'd say it's a nonblocker as slurpd dates back to 2.2 and was only left for migration, today you should be using syncprov it has also been dropped on 2.4 already, so no objections to still mark stable
(In reply to comment #14) > I'd say it's a nonblocker as slurpd dates back to 2.2 and was only left for > migration, today you should be using syncprov > it has also been dropped on 2.4 already, so no objections to still mark stable OK, stable for HPPA.
Fixed in release snapshot.
GLSA 200803-28
Unsure if this is the same bug but it looks similar enough to me... i just installed openldap-2.3.41 today (sync'd this afternoon) and was attempting to ldapadd some test data. slapd crashes. if i supply an incorrect password it stays stable, as soon as i supply the real password it crashes immediately - no syslog output, daemon gone! # /etc/init.d/slapd restart ... # ldapadd -x -D "cn=Manager,dc=domain,dc=com" -W -f `locate .ldif` Enter LDAP Password: (dont enter any or enter wrong) ldap_bind: Server is unwilling to perform (53) additional info: unauthenticated bind (DN with no password) disallowed (daemon is still running) # ldapadd -x -D "cn=Manager,dc=domain,dc=com" -W -f `locate .ldif` Enter LDAP Password: (enter correct password) ldap_result: Can't contact LDAP server (-1) # (daemon is gone) Architecture: -march=k8 -O2 -pipe -fomit-frame-pointer ... AMD Athlon(tm) 64 Processor 30000+
Walter: Are you sure you configured the LDAP server correctly? In any case, please open a new bug for it, if you believe this to be a bug in OpenLDAP. But make sure you have your configuration right before that.
