May 2008 - openldap-bugs

(ITS#5517) add superclass of existing class fails

by h.b.furuseth＠usit.uio.no

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard If objectclass B is a subclass of A, and an entry contains objectclass B but not A, slapd returns attributeOrValueExists to a request to add A. OTOH it allows replace(objectClass: <A, B>), and after that it allows delete(objectClass: A). This is inconsistent. If the objectClass attribute contains B, does it "really" contain A as well? I couldn't find such a statement in the RFCs, so my guess is that add(objectClass: A) should be allowed. Though I haven't looked all that hard. Example: ldapadd -cx <<'EOF' # Create initial object dn: c=NO objectClass: friendlyCountry c: NO co: Norway # error dn: c=NO changetype: modify add: objectClass objectClass: top - # error dn: c=NO changetype: modify add: objectClass objectClass: country - # success dn: c=NO changetype: modify replace: objectClass objectClass: top objectClass: country objectClass: friendlyCountry - # success dn: c=NO changetype: modify delete: objectClass objectClass: top - # success dn: c=NO changetype: modify delete: objectClass objectClass: country - EOF

14 years, 10 months

1
0
0 / 0

Re: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly

by bpgoldsb＠gleim.com

We're using *.domain.tld in the CN and subjectAltName:DNS:*.domain.tld This may be a GnuTLS issue, as I am able to reproduce it with the GnuTLS server/client testing tools. On Sat, 2008-05-17 at 23:23 -0700, Howard Chu wrote: > bgoldsbury(a)gleim.com wrote: > > Full_Name: Ben Goldsbury > > Version: 2.4.9 > > OS: Debian > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (209.208.68.2) > > > > > > When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) and > > using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with: > > > > TLS certificate verification: Error, unable to get local issuer certificate > > > > When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing) > > and using the same certificate, connections work properly. > > > > Please contact me if you need any additional information. > > This sounds an awful lot like ITS#5361, which is a known defect in GnuTLS. > > What exactly do you mean by "Wildcard SSL certificate" ? There are a couple > different approaches to that. One uses the subjectAltName extension, and that > is the officially sanctioned approach. One uses "*" in the certificate CN, and > that is non-standard and generally not supposed to work.

14 years, 10 months

1
0
0 / 0

Re: (ITS#5513) back-ldap+ppolicy bind assertion failure

by ando＠sys-net.it

mbackes(a)symas.com wrote: > Thanks; this seems to fix the issue, at least in my test cases. OK, I've applied the fix to re23/re24 as well. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

14 years, 10 months

1
0
0 / 0

Re: (ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly

by hyc＠symas.com

bgoldsbury(a)gleim.com wrote: > Full_Name: Ben Goldsbury > Version: 2.4.9 > OS: Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.208.68.2) > > > When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) and > using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with: > > TLS certificate verification: Error, unable to get local issuer certificate > > When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing) > and using the same certificate, connections work properly. > > Please contact me if you need any additional information. This sounds an awful lot like ITS#5361, which is a known defect in GnuTLS. What exactly do you mean by "Wildcard SSL certificate" ? There are a couple different approaches to that. One uses the subjectAltName extension, and that is the officially sanctioned approach. One uses "*" in the certificate CN, and that is non-standard and generally not supposed to work. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 10 months

1
0
0 / 0

Re: (ITS#5513) back-ldap+ppolicy bind assertion failure

by mbackes＠symas.com

> I've been able to reproduce the issue, and I think it's solved > (back-ldap/search.c 1.235 -> 1.236); however I'm afraid I didn't > understand all the details of your configuration, so I might have > tested something different. > > The bug was in ldap_back_entry_get() setting up a connection based > on the o_tag field, which is that of the current operation (a bind, > in your case). I fixed it by always re-setting the tag to > LDAP_REQ_SEARCH, under the assumption that ldap_back_entry_get() > doesn't need to know what operation required the entry to be looked > up. > > Please test and report; in case of further issues, I might need the > full slapd.conf of the proxy (unless the above is all, of course...) Thanks; this seems to fix the issue, at least in my test cases. Matthew Backes Symas Corporation mbackes(a)symas.com

14 years, 10 months

1
0
0 / 0

(ITS#5516) acl_set_cb_gather() incorrectly handles multiple attrs

by ando＠sys-net.it

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Only the last attribute is considered. Reported in <http://www.openldap.org/lists/openldap-devel/200805/msg00075.html>. A fix is coming.

14 years, 10 months

1
0
0 / 0

Re: (ITS#5513) back-ldap+ppolicy bind assertion failure

by ando＠sys-net.it

mbackes(a)symas.com wrote: > A basic back-ldap configuration with the password policy overlay stacked on top > results in an assertfail for the second bind. e.g. given a working (possibly > empty db) on ldap://localhost:1389/... > > include ...../core.schema > include ...../ppolicy.schema > > modulepath ..... > moduleload back_ldap.la > moduleload ppolicy.la > > database ldap > suffix "" > uri ldap://localhost:1389/ > > After performing a successful remote bind, the next bind attempt halts the > back-ldap directory with: > > slapd: bind.c:905: ldap_back_getconn: Assertion `( li->li_idassert.si_flags & > (0x02U) )' failed. > > where 0x02U here is LDAP_BACK_AUTH_OVERRIDE. > > This happens under both OpenLDAP 2.3 and 2.4. I've been able to reproduce the issue, and I think it's solved (back-ldap/search.c 1.235 -> 1.236); however I'm afraid I didn't understand all the details of your configuration, so I might have tested something different. The bug was in ldap_back_entry_get() setting up a connection based on the o_tag field, which is that of the current operation (a bind, in your case). I fixed it by always re-setting the tag to LDAP_REQ_SEARCH, under the assumption that ldap_back_entry_get() doesn't need to know what operation required the entry to be looked up. Please test and report; in case of further issues, I might need the full slapd.conf of the proxy (unless the above is all, of course...) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

14 years, 10 months

1
0
0 / 0

Re: (ITS#5502) LDAP problem

by ando＠sys-net.it

javed_ansari(a)infosys.com wrote: > Full_Name: Javed Ansari > Version: 2.3.30 > OS: Sun > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (220.225.64.6) > > > Since yesterday, we are facing LDAP problems while insertion of data. When we > try to insert data in the ldap we get the following error: > > [LDAP: error code 80 - entry store failed] > > There however seems to be no problem with the login though, this occurs only > during registration You seem to be a little bit too confident on our capability to predict the server's behavior based on a very limited amount of information. Based on the accuracy of your issue report, all I can tell is that you seem to have a problem. Please follow guidelines at <http://www.openldap.org/faq/data/cache/56.html> and provide a decent issue report. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

14 years, 10 months

1
0
0 / 0

(ITS#5515) v2.4.9 + GnuTLS fails with wildcard certificate, OpenSSL works correctly

by bgoldsbury＠gleim.com

Full_Name: Ben Goldsbury Version: 2.4.9 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.208.68.2) When OpenLDAP 2.4.9 is compiled against GnuTLS (version 2.2.1 in my testing) and using a valid Wildcard SSL certificate, TLS connections to OpenLDAP fail with: TLS certificate verification: Error, unable to get local issuer certificate When OpenLDAP 2.4.9 is compiled against OpenSSL (version 0.9.8c in my testing) and using the same certificate, connections work properly. Please contact me if you need any additional information.

14 years, 10 months

1
0
0 / 0

Re: (ITS#5510) Does GSSAPI failure kill slapd?

by h.b.furuseth＠usit.uio.no

hyc(a)symas.com writes: > This looks like a pretty major compiler bug, assuming the trace is > correct. Not necessarily, valid optimizations can rearrange memory beyond a debugger's ability to figure out what's going on. Still, this does look like a strange optimization if it's a valid one. > What version of compiler did you use, were you using optimization? Can > you try with a different version and/or without optimization? -- Hallvard

14 years, 10 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2008