openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#7044) objectIdentifier not usable for reference in objectClass' MUST or MAY clause
by hyc＠symas.com 18 Sep '11

18 Sep '11

carsten.klein(a)axn-software.de wrote: > Full_Name: Carsten Klein > Version: 2.4.23 > OS: Kubuntu 11.01 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.54.26.231) > > > I tried to get rid of the global namespace restrictions regarding attributeType > names by declaring objectIdentifierS for each of the attributeTypeS forefront > and then use these both for declaring the attributeTypeS and also using them for > reference in a MAY or MUST clause in the declared objectClassES > > While the attributeType declaration works just fine, the objectClassES will not > be parsed, resulting in an error stating that the OID cannot be resolved. > > How to reproduce: > > > objectIdentifier fooOID 1.3.6.1.4.1.123456789 > objectIdentifier fooAttrOID fooOID:1 > objectIdentifier fooClassOID fooOID:2 > > attributeType ( fooAttrOID NAME 'fooAttr' > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > > objectClass ( fooClassOID NAME 'fooClass' SUP top STRUCTURAL > MAY ( fooAttrOID ) ) > > will not work as expected. > > However, replacing fooAttrOID in the above objectClass declaration by either > fooAttr or 1.3.6.1.4.1.38570.1 will produce a valid ldif when run through > slaptest. > > I believe that the expected behaviour should be that the declared > objectIdentifier fooAttrOID should also be recognized when parsing the MAY or > MUST clause of the objectClass declaration. > > Or is there a way to force slaptest to recognize it? This is not supported. It is normal practice to use the canonical names of attributes in objectclass definitions, for readability. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7043) double free or corruption error
by hyc＠symas.com 18 Sep '11

18 Sep '11

szinski(a)richmond.edu wrote: > Full_Name: Steve Zinski > Version: 2.4.23 > OS: RHEL6 x64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (141.166.34.143) Looks like this is the same as ITS#7034, closing this one. > > *** glibc detected *** slapd: double free or corruption (fasttop): > 0x00007f798831b2c0 *** > ======= Backtrace: ========= > /lib64/libc.so.6(+0x379a875146)[0x7f79c5ee7146] > /usr/lib64/libnsspem.so(+0x18e72)[0x7f79ae93ae72] > /usr/lib64/libnsspem.so(+0xa4f4)[0x7f79ae92c4f4] > /usr/lib64/libnsspem.so(+0xa64d)[0x7f79ae92c64d] > /usr/lib64/libnsspem.so(+0x1806f)[0x7f79ae93a06f] > /usr/lib64/libnsspem.so(+0x14491)[0x7f79ae936491] > /usr/lib64/libnss3.so(+0x37a184f55d)[0x7f79c6ccf55d] > /usr/lib64/libnss3.so(+0x37a18500c8)[0x7f79c6cd00c8] > /usr/lib64/libnss3.so(PK11_PubUnwrapSymKey+0xac)[0x7f79c6cd071c] > /usr/lib64/libssl3.so(+0x37a1012d52)[0x7f79c71f9d52] > /usr/lib64/libssl3.so(+0x37a1013e30)[0x7f79c71fae30] > /usr/lib64/libssl3.so(+0x37a10148cc)[0x7f79c71fb8cc] > /usr/lib64/libssl3.so(SSL_ForceHandshake+0x4f)[0x7f79c720562f] > slapd(+0x16ee65)[0x7f79c8392e65] > slapd(ldap_pvt_tls_accept+0x77)[0x7f79c8392097] > slapd(+0x4a8bb)[0x7f79c826e8bb] > slapd(+0x149c18)[0x7f79c836dc18] > /lib64/libpthread.so.0(+0x379b0077e1)[0x7f79c62087e1] > /lib64/libc.so.6(clone+0x6d)[0x7f79c5f5777d] > ======= Memory map: ======== > 7f7980000000-7f7980b86000 rw-p 00000000 00:00 0 > 7f7980b86000-7f7984000000 ---p 00000000 00:00 0 > 7f7986de1000-7f7986df7000 r-xp 00000000 fd:00 1572887 > /lib64/libgcc_s-4.4.5-20110214.so.1 > 7f7986df7000-7f7986ff6000 ---p 00016000 fd:00 1572887 > /lib64/libgcc_s-4.4.5-20110214.so.1 > 7f7986ff6000-7f7986ff7000 rw-p 00015000 fd:00 1572887 > /lib64/libgcc_s-4.4.5-20110214.so.1 > 7f7986ffe000-7f7988000000 rw-p 00000000 00:00 0 > 7f7988000000-7f7988a3e000 rw-p 00000000 00:00 0 > 7f7988a3e000-7f798c000000 ---p 00000000 00:00 0 > 7f798c000000-7f798c3de000 rw-p 00000000 00:00 0 > 7f798c3de000-7f7990000000 ---p 00000000 00:00 0 > 7f7990000000-7f79904bb000 rw-p 00000000 00:00 0 > 7f79904bb000-7f7994000000 ---p 00000000 00:00 0 > 7f79947fc000-7f79947fd000 ---p 00000000 00:00 0 > 7f79947fd000-7f7998000000 rw-p 00000000 00:00 0 > 7f7998000000-7f7998b64000 rw-p 00000000 00:00 0 > 7f7998b64000-7f799c000000 ---p 00000000 00:00 0 > 7f799c7fb000-7f799c7fc000 ---p 00000000 00:00 0 > 7f799c7fc000-7f799effe000 rw-p 00000000 00:00 0 > 7f799effe000-7f799efff000 ---p 00000000 00:00 0 > 7f799efff000-7f799f7ff000 rw-p 00000000 00:00 0 > 7f799f7ff000-7f799f800000 ---p 00000000 00:00 0 > 7f799f800000-7f79a0000000 rw-p 00000000 00:00 0 > 7f79a0000000-7f79a1b52000 rw-p 00000000 00:00 0 > 7f79a1b52000-7f79a4000000 ---p 00000000 00:00 0 > 7f79a4000000-7f79a4bb2000 rw-p 00000000 00:00 0 > 7f79a4bb2000-7f79a8000000 ---p 00000000 00:00 0 > 7f79a8000000-7f79a8021000 rw-p 00000000 00:00 0 > 7f79a8021000-7f79ac000000 ---p 00000000 00:00 0 > 7f79ac3bb000-7f79ac3bc000 ---p 00000000 00:00 0 > 7f79ac3bc000-7f79acbbc000 rw-p 00000000 00:00 0 > 7f79acbbc000-7f79acbbd000 ---p 00000000 00:00 0 > 7f79acbbd000-7f79ae922000 rw-p 00000000 00:00 0 > 7f79ae922000-7f79ae954000 r-xp 00000000 fd:00 1707035 > /usr/lib64/libnsspem.so > 7f79ae954000-7f79aeb53000 ---p 00032000 fd:00 1707035 > /usr/lib64/libnsspem.so > 7f79aeb53000-7f79aeb59000 rw-p 00031000 fd:00 1707035 > /usr/lib64/libnsspem.so > 7f79aeb59000-7f79aebe5000 r-xp 00000000 fd:00 1708690 > /usr/lib64/libsqlite3.so.0.8.6 > 7f79aebe5000-7f79aede4000 ---p 0008c000 fd:00 1708690 > /usr/lib64/libsqlite3.so.0.8.6 > 7f79aede4000-7f79aede8000 rw-p 0008b000 fd:00 1708690 > /usr/lib64/libsqlite3.so.0.8.6 > 7f79aede8000-7f79aee24000 r-xp 00000000 fd:00 1706243 > /usr/lib64/libsoftokn3.so > 7f79aee24000-7f79af024000 ---p 0003c000 fd:00 1706243 > /usr/lib64/libsoftokn3.so > 7f79af024000-7f79af026000 rw-p 0003c000 fd:00 1706243 > /usr/lib64/libsoftokn3.so > 7f79af026000-7f79af027000 ---p 00000000 00:00 0 > 7f79af027000-7f79af827000 rw-p 00000000 00:00 0 > 7f79af827000-7f79af828000 ---p 00000000 00:00 0 > 7f79af828000-7f79b0028000 rw-p 00000000 00:00 0 > 7f79b0028000-7f79b00e2000 rw-s 00000000 fd:00 919129 > /var/lib/ldap/__db.005 > 7f79b00e2000-7f79b0322000 rw-s 00000000 fd:00 919128 > /var/lib/ldap/__db.004 > 7f79b0322000-7f79c4324000 rw-s 00000000 fd:00 919125 > /var/lib/ldap/__db.003 > 7f79c4324000-7f79c4bd2000 rw-s 00000000 fd:00 918259 > /var/lib/ldap/__db.002 > 7f79c4bd2000-7f79c4bd6000 r-xp 00000000 fd:00 1705113 > /usr/lib64/sasl2/libanonymous.so.2.0.23 > 7f79c4bd6000-7f79c4dd5000 ---p 00004000 fd:00 1705113 > /usr/lib64/sasl2/libanonymous.so.2.0.23 > 7f79c4dd5000-7f79c4dd6000 rw-p 00003000 fd:00 1705113 > /usr/lib64/sasl2/libanonymous.so.2.0.23 > 7f79c4dd6000-7f79c4ddb000 r-xp 00000000 fd:00 1705116 > /usr/lib64/sasl2/libsasldb.so.2.0.23 > 7f79c4ddb000-7f79c4fda000 ---p 00005000 fd:00 1705116 > /usr/lib64/sasl2/libsasldb.so.2.0.23 > 7f79c4fda000-7f79c4fdb000 rw-p 00004000 fd:00 1705116 > /usr/lib64/sasl2/libsasldb.so.2.0.23 > 7f79c4fdb000-7f79c4fdf000 r-xp 00000000 fd:00 1710213 > /usr/lib64/sasl2/libplain.so.2.0.23 > 7f79c4fdf000-7f79c51de000 ---p 00004000 fd:00 1710213 > /usr/lib64/sasl2/libplain.so.2.0.23 > 7f79c51de000-7f79c51df000 rw-p 00003000 fd:00 1710213 > /usr/lib64/sasl2/libplain.so.2.0.23 > 7f79c51df000-7f79c51e3000 r-xp 00000000 fd:00 1710210 > /usr/lib64/sasl2/liblogin.so.2.0.23 > 7f79c51e3000-7f79c53e2000 ---p 00004000 fd:00 1710210 > /usr/lib64/sasl2/liblogin.so.2.0.23 > 7f79c53e2000-7f79c53e3000 rw-p 00003000 fd:00 1710210 > /usr/lib64/sasl2/liblogin.so.2.0.23 > 7f79c53e3000-7f79c53e8000 r-xp 00000000 fd:00 1572890 > /lib64/libnss_dns-2.12.so > 7f79c53e8000-7f79c55e7000 ---p 00005000 fd:00 1572890 > /lib64/libnss_dns-2.12.so > 7f79c55e7000-7f79c55e8000 r--p 00004000 fd:00 1572890 > /lib64/libnss_dns-2.12.so > 7f79c55e8000-7f79c55e9000 rw-p 00005000 fd:00 1572890 > /lib64/libnss_dns-2.12.so > 7f79c55e9000-7f79c55f5000 r-xp 00000000 fd:00 1573202 > /lib64/libnss_files-2.12.so > 7f79c55f5000-7f79c57f5000 ---p 0000c000 fd:00 1573202 > /lib64/libnss_files-2.12.so > 7f79c57f5000-7f79c57f6000 r--p 0000c000 fd:00 1573202 > /lib64/libnss_files-2.12.so > 7f79c57f6000-7f79c57f7000 rw-p 0000d000 fd:00 1573202 > /lib64/libnss_files-2.12.so > 7f79c57f7000-7f79c580c000 r-xp 00000000 fd:00 1573233 > /lib64/libz.so.1.2.3 > 7f79c580c000-7f79c5a0b000 ---p 00015000 fd:00 1573233 > /lib64/libz.so.1.2.3 > 7f79c5a0b000-7f79c5a0c000 rw-p 00014000 fd:00 1573233 > /lib64/libz.so.1.2.3 > 7f79c5a0c000-7f79c5a69000 r-xp 00000000 fd:00 1572935 > /lib64/libfreebl3.soAborted > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7044) objectIdentifier not usable for reference in objectClass' MUST or MAY clause
by carsten.klein＠axn-software.de 15 Sep '11

15 Sep '11

Full_Name: Carsten Klein Version: 2.4.23 OS: Kubuntu 11.01 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.54.26.231) I tried to get rid of the global namespace restrictions regarding attributeType names by declaring objectIdentifierS for each of the attributeTypeS forefront and then use these both for declaring the attributeTypeS and also using them for reference in a MAY or MUST clause in the declared objectClassES While the attributeType declaration works just fine, the objectClassES will not be parsed, resulting in an error stating that the OID cannot be resolved. How to reproduce: objectIdentifier fooOID 1.3.6.1.4.1.123456789 objectIdentifier fooAttrOID fooOID:1 objectIdentifier fooClassOID fooOID:2 attributeType ( fooAttrOID NAME 'fooAttr' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) objectClass ( fooClassOID NAME 'fooClass' SUP top STRUCTURAL MAY ( fooAttrOID ) ) will not work as expected. However, replacing fooAttrOID in the above objectClass declaration by either fooAttr or 1.3.6.1.4.1.38570.1 will produce a valid ldif when run through slaptest. I believe that the expected behaviour should be that the declared objectIdentifier fooAttrOID should also be recognized when parsing the MAY or MUST clause of the objectClass declaration. Or is there a way to force slaptest to recognize it?

1 0

(ITS#7043) double free or corruption error
by szinski＠richmond.edu 13 Sep '11

13 Sep '11

Full_Name: Steve Zinski Version: 2.4.23 OS: RHEL6 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.166.34.143) *** glibc detected *** slapd: double free or corruption (fasttop): 0x00007f798831b2c0 *** ======= Backtrace: ========= /lib64/libc.so.6(+0x379a875146)[0x7f79c5ee7146] /usr/lib64/libnsspem.so(+0x18e72)[0x7f79ae93ae72] /usr/lib64/libnsspem.so(+0xa4f4)[0x7f79ae92c4f4] /usr/lib64/libnsspem.so(+0xa64d)[0x7f79ae92c64d] /usr/lib64/libnsspem.so(+0x1806f)[0x7f79ae93a06f] /usr/lib64/libnsspem.so(+0x14491)[0x7f79ae936491] /usr/lib64/libnss3.so(+0x37a184f55d)[0x7f79c6ccf55d] /usr/lib64/libnss3.so(+0x37a18500c8)[0x7f79c6cd00c8] /usr/lib64/libnss3.so(PK11_PubUnwrapSymKey+0xac)[0x7f79c6cd071c] /usr/lib64/libssl3.so(+0x37a1012d52)[0x7f79c71f9d52] /usr/lib64/libssl3.so(+0x37a1013e30)[0x7f79c71fae30] /usr/lib64/libssl3.so(+0x37a10148cc)[0x7f79c71fb8cc] /usr/lib64/libssl3.so(SSL_ForceHandshake+0x4f)[0x7f79c720562f] slapd(+0x16ee65)[0x7f79c8392e65] slapd(ldap_pvt_tls_accept+0x77)[0x7f79c8392097] slapd(+0x4a8bb)[0x7f79c826e8bb] slapd(+0x149c18)[0x7f79c836dc18] /lib64/libpthread.so.0(+0x379b0077e1)[0x7f79c62087e1] /lib64/libc.so.6(clone+0x6d)[0x7f79c5f5777d] ======= Memory map: ======== 7f7980000000-7f7980b86000 rw-p 00000000 00:00 0 7f7980b86000-7f7984000000 ---p 00000000 00:00 0 7f7986de1000-7f7986df7000 r-xp 00000000 fd:00 1572887 /lib64/libgcc_s-4.4.5-20110214.so.1 7f7986df7000-7f7986ff6000 ---p 00016000 fd:00 1572887 /lib64/libgcc_s-4.4.5-20110214.so.1 7f7986ff6000-7f7986ff7000 rw-p 00015000 fd:00 1572887 /lib64/libgcc_s-4.4.5-20110214.so.1 7f7986ffe000-7f7988000000 rw-p 00000000 00:00 0 7f7988000000-7f7988a3e000 rw-p 00000000 00:00 0 7f7988a3e000-7f798c000000 ---p 00000000 00:00 0 7f798c000000-7f798c3de000 rw-p 00000000 00:00 0 7f798c3de000-7f7990000000 ---p 00000000 00:00 0 7f7990000000-7f79904bb000 rw-p 00000000 00:00 0 7f79904bb000-7f7994000000 ---p 00000000 00:00 0 7f79947fc000-7f79947fd000 ---p 00000000 00:00 0 7f79947fd000-7f7998000000 rw-p 00000000 00:00 0 7f7998000000-7f7998b64000 rw-p 00000000 00:00 0 7f7998b64000-7f799c000000 ---p 00000000 00:00 0 7f799c7fb000-7f799c7fc000 ---p 00000000 00:00 0 7f799c7fc000-7f799effe000 rw-p 00000000 00:00 0 7f799effe000-7f799efff000 ---p 00000000 00:00 0 7f799efff000-7f799f7ff000 rw-p 00000000 00:00 0 7f799f7ff000-7f799f800000 ---p 00000000 00:00 0 7f799f800000-7f79a0000000 rw-p 00000000 00:00 0 7f79a0000000-7f79a1b52000 rw-p 00000000 00:00 0 7f79a1b52000-7f79a4000000 ---p 00000000 00:00 0 7f79a4000000-7f79a4bb2000 rw-p 00000000 00:00 0 7f79a4bb2000-7f79a8000000 ---p 00000000 00:00 0 7f79a8000000-7f79a8021000 rw-p 00000000 00:00 0 7f79a8021000-7f79ac000000 ---p 00000000 00:00 0 7f79ac3bb000-7f79ac3bc000 ---p 00000000 00:00 0 7f79ac3bc000-7f79acbbc000 rw-p 00000000 00:00 0 7f79acbbc000-7f79acbbd000 ---p 00000000 00:00 0 7f79acbbd000-7f79ae922000 rw-p 00000000 00:00 0 7f79ae922000-7f79ae954000 r-xp 00000000 fd:00 1707035 /usr/lib64/libnsspem.so 7f79ae954000-7f79aeb53000 ---p 00032000 fd:00 1707035 /usr/lib64/libnsspem.so 7f79aeb53000-7f79aeb59000 rw-p 00031000 fd:00 1707035 /usr/lib64/libnsspem.so 7f79aeb59000-7f79aebe5000 r-xp 00000000 fd:00 1708690 /usr/lib64/libsqlite3.so.0.8.6 7f79aebe5000-7f79aede4000 ---p 0008c000 fd:00 1708690 /usr/lib64/libsqlite3.so.0.8.6 7f79aede4000-7f79aede8000 rw-p 0008b000 fd:00 1708690 /usr/lib64/libsqlite3.so.0.8.6 7f79aede8000-7f79aee24000 r-xp 00000000 fd:00 1706243 /usr/lib64/libsoftokn3.so 7f79aee24000-7f79af024000 ---p 0003c000 fd:00 1706243 /usr/lib64/libsoftokn3.so 7f79af024000-7f79af026000 rw-p 0003c000 fd:00 1706243 /usr/lib64/libsoftokn3.so 7f79af026000-7f79af027000 ---p 00000000 00:00 0 7f79af027000-7f79af827000 rw-p 00000000 00:00 0 7f79af827000-7f79af828000 ---p 00000000 00:00 0 7f79af828000-7f79b0028000 rw-p 00000000 00:00 0 7f79b0028000-7f79b00e2000 rw-s 00000000 fd:00 919129 /var/lib/ldap/__db.005 7f79b00e2000-7f79b0322000 rw-s 00000000 fd:00 919128 /var/lib/ldap/__db.004 7f79b0322000-7f79c4324000 rw-s 00000000 fd:00 919125 /var/lib/ldap/__db.003 7f79c4324000-7f79c4bd2000 rw-s 00000000 fd:00 918259 /var/lib/ldap/__db.002 7f79c4bd2000-7f79c4bd6000 r-xp 00000000 fd:00 1705113 /usr/lib64/sasl2/libanonymous.so.2.0.23 7f79c4bd6000-7f79c4dd5000 ---p 00004000 fd:00 1705113 /usr/lib64/sasl2/libanonymous.so.2.0.23 7f79c4dd5000-7f79c4dd6000 rw-p 00003000 fd:00 1705113 /usr/lib64/sasl2/libanonymous.so.2.0.23 7f79c4dd6000-7f79c4ddb000 r-xp 00000000 fd:00 1705116 /usr/lib64/sasl2/libsasldb.so.2.0.23 7f79c4ddb000-7f79c4fda000 ---p 00005000 fd:00 1705116 /usr/lib64/sasl2/libsasldb.so.2.0.23 7f79c4fda000-7f79c4fdb000 rw-p 00004000 fd:00 1705116 /usr/lib64/sasl2/libsasldb.so.2.0.23 7f79c4fdb000-7f79c4fdf000 r-xp 00000000 fd:00 1710213 /usr/lib64/sasl2/libplain.so.2.0.23 7f79c4fdf000-7f79c51de000 ---p 00004000 fd:00 1710213 /usr/lib64/sasl2/libplain.so.2.0.23 7f79c51de000-7f79c51df000 rw-p 00003000 fd:00 1710213 /usr/lib64/sasl2/libplain.so.2.0.23 7f79c51df000-7f79c51e3000 r-xp 00000000 fd:00 1710210 /usr/lib64/sasl2/liblogin.so.2.0.23 7f79c51e3000-7f79c53e2000 ---p 00004000 fd:00 1710210 /usr/lib64/sasl2/liblogin.so.2.0.23 7f79c53e2000-7f79c53e3000 rw-p 00003000 fd:00 1710210 /usr/lib64/sasl2/liblogin.so.2.0.23 7f79c53e3000-7f79c53e8000 r-xp 00000000 fd:00 1572890 /lib64/libnss_dns-2.12.so 7f79c53e8000-7f79c55e7000 ---p 00005000 fd:00 1572890 /lib64/libnss_dns-2.12.so 7f79c55e7000-7f79c55e8000 r--p 00004000 fd:00 1572890 /lib64/libnss_dns-2.12.so 7f79c55e8000-7f79c55e9000 rw-p 00005000 fd:00 1572890 /lib64/libnss_dns-2.12.so 7f79c55e9000-7f79c55f5000 r-xp 00000000 fd:00 1573202 /lib64/libnss_files-2.12.so 7f79c55f5000-7f79c57f5000 ---p 0000c000 fd:00 1573202 /lib64/libnss_files-2.12.so 7f79c57f5000-7f79c57f6000 r--p 0000c000 fd:00 1573202 /lib64/libnss_files-2.12.so 7f79c57f6000-7f79c57f7000 rw-p 0000d000 fd:00 1573202 /lib64/libnss_files-2.12.so 7f79c57f7000-7f79c580c000 r-xp 00000000 fd:00 1573233 /lib64/libz.so.1.2.3 7f79c580c000-7f79c5a0b000 ---p 00015000 fd:00 1573233 /lib64/libz.so.1.2.3 7f79c5a0b000-7f79c5a0c000 rw-p 00014000 fd:00 1573233 /lib64/libz.so.1.2.3 7f79c5a0c000-7f79c5a69000 r-xp 00000000 fd:00 1572935 /lib64/libfreebl3.soAborted

1 0

Re: (ITS#7041) Slapcat exporting bad data?
by Pierangelo Masarati 12 Sep '11

12 Sep '11

The value you see loginEmail:: IGpvY2tleTc1QGhvdG1haWwuY29t is $ echo -n 'IGpvY2tleTc1QGhvdG1haWwuY29t' | base64 -d && echo "" jockey75(a)hotmail.com (note the leading space). I suspect garbage in-garbage out, where LDAP browser is probably hiding garbage by trimming the leading space. You should check with ldapsearch(1) instead. Looks like incorrect data rather than a bug in slapcat(8). p.

1 0

Re: (ITS#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by Kurt＠OpenLDAP.org 12 Sep '11

12 Sep '11

I note that third-party patch submissions cannot be accepted per our IPR policies. The original author is required to submit their own patches. -- Kurt

1 0

Re: (ITS#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by jvcelak＠redhat.com 12 Sep '11

12 Sep '11

On Monday 12 September 2011 19:00:08, Howard Chu wrote: > Thanks for passing along the report, but I'm not convinced this is a > legitimate issue. Servers that trust each other for replication should > accept each other's TLS certificates. As I see it, if their certs aren't > working in this configuration then their certificates were created with > the wrong usage flags, and this is not an OpenLDAP issue. You are definitely right. But disabling the options still might be useful for some people. Including the author of the patch. I think it is a very simple change which adds some extra bonus to current functionality. Nothing critical and no regressions are likely. It would be great, if you could include the patch even if you do not absolutely agree with disabling the client certificate authentication for replication. -- Jan Včelák Base Operating Systems Brno Red Hat Inc.

1 0

Re: (ITS#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by hyc＠symas.com 12 Sep '11

12 Sep '11

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-20110912-syncrepl-allow-unsetting-o… > Submission from: (NULL) (209.132.186.34) > > > Hello, > > I'm just passing a patch submitted to our bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=734187 > > To sum it up: If tls_cert/tls_key syncrepl options are not specified, server > setting is inherited and used. According to various reports on the Internet, > this is a feature, not a bug. Relying on hearsay "According to various reports on the Internet" is a stupid way to get information, particularly when it's already documented in the slapd.conf(5) and slapd-config(5) manpages. > However it forces a replica to use a client > certificate for authentication, because the tls_cert and tls_key options can not > be disabled. > > The patch allows tls_* options to be disabled, like this: "tls_cert=" > Without the patch, "file not found" error will occur. > The patch is written by the submitter of the bug report - Patrick Monnerat (pm > at datasphere dot ch). Thanks for passing along the report, but I'm not convinced this is a legitimate issue. Servers that trust each other for replication should accept each other's TLS certificates. As I see it, if their certs aren't working in this configuration then their certificates were created with the wrong usage flags, and 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/

1 0

(ITS#7042) [PATCH] allow unsetting of tls_* options for syncrepl
by jvcelak＠redhat.com 12 Sep '11

12 Sep '11

Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-20110912-syncrepl-allow-unsetting-o… Submission from: (NULL) (209.132.186.34) Hello, I'm just passing a patch submitted to our bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=734187 To sum it up: If tls_cert/tls_key syncrepl options are not specified, server setting is inherited and used. According to various reports on the Internet, this is a feature, not a bug. However it forces a replica to use a client certificate for authentication, because the tls_cert and tls_key options can not be disabled. The patch allows tls_* options to be disabled, like this: "tls_cert=" Without the patch, "file not found" error will occur. The patch is written by the submitter of the bug report - Patrick Monnerat (pm at datasphere dot ch). Jan

1 0

Re: (ITS#6925) [PATCH] Use inet_ntop for server when available
by masarati＠aero.polimi.it 08 Sep '11

08 Sep '11

>> Uploaded as xinli-its6925-110630.patch. > > Sorry, apparently I never received this message. It is not clear why you > conditioned it based on HAVE_GETADDRINFO; this seems to be repeated also > throughout the original code. > > The patch is not fine in slapd/daemon.c (the original code seems to be > broken as > well where inet_ntop(3) is already used), since peeraddr is set by > inet_ntop(3) > to point to the buffer addr[], and is used also when addr[] gets out of > scope > (#ifdef HAVE_TCPD). Fixing. The patch and the fixes are in git's master. In the commit log I forgot to mention that many of those fixes, significantly that for LDAP_CONNECTIONLESS, are blind. Please test and report. p.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs