openldap-bugs

openldap-bugs@openldap.org

20960 discussions

(ITS#8144) SegV in ~LDAPCtrl()
by jianying.luo＠alcatel-lucent.com 15 May '15

15 May '15

Full_Name: Jianying Luo Version: 2.4.40 OS: RHEL 2.6.32-504.12.2.el6.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.245.8.2) Hi, >From the 2.4.40 changelog, I saw "Fixed ldapc++ memory leak in Async connection (ITS#7806)". The code change is at openldap-2.4.40/contrib/ldapc++/src/LDAPAsynConnection.cpp -Del- 46 LPAsysynConnection::~LDAPAsynConnection(){} +Add+ 46 LDAPAsynConnection::~LDAPAsynConnection(){ +Add+ 47 unbind(); +Add+ 48 delete m_constr; +Add+ 49 } But this caused a segV #0 0x00c40a79 in __gnu_cxx::__exchange_and_add(int volatile*, int) () from /usr/lib/libstdc++.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.5.i686 libgcc-4.4.7-11.el6.i686 libstdc++-4.4.7-11.el6.i686 (gdb) bt #0 0x00c40a79 in __gnu_cxx::__exchange_and_add(int volatile*, int) (9 9 from /usr/lib/libstdc++.so.6 #1 0x005e05c1 in ::~LDAPCtrl() () from /opt/LU3P/lib/libldapcpp.so.0 #2 0x005e0c7f in LDAPControlSet::~LDAPControlSet() () from /opt/LU3P/lib/libldapcpp.so.0 #3 0x005e02a3 in LDAPConstraints::~LDAPConstraints() () from /opt/LU3P/lib/libldapcpp.so.0 #4 0x005da82f in LDAPAsynConnection::~LDAPAsynConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #5 0x005dfa98 in LDAPConnection::~LDAPConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #6 0x005dfac2 in LDAPConnection::~LDAPConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #7 0x0805e189 in CpmLDAPOper::~CpmLDAPOper (this=0x82fc630, __in_chrg=<value optimized out>) at ../../../../../../glob/src/cpm_daemon/CpmLDAPOper.cpp:54 #8 0x0806486a in CpmMonMain::ReadFeatureOption (this=0x82fa228, force=1 '\001') at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:332 #9 0x08065c8c in CpmMonMain::CheckState (this=0x82fa228) at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:473 #10 0x08065ec0 in CpmMonMain::LoopWork (this=0x82fa228) at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:256 #11 0x0805348a in CpmMainBase::Run (this=0x82fa228, argc=1, argv=0xffcbe944) at ../../../../../../glob/src/cpm_daemon/CpmMainBase.cpp:156 #12 0x0806435d in main (argc=1, argv=0xffcbe944) at ../..F.F../../../../glob/src/cpm_daemon/CpmMonMain.cpp:517 (gdb) q Thanks, Jianying

1 0

(ITS#8143) SegV in ~LDAPCtrl()
by jianying.luo＠alcatel-lucent.com 14 May '15

14 May '15

Full_Name: Jianying Luo Version: 2.4.40 OS: RHEL 2.6.32-504.12.2.el6.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.245.8.3) Hi, >From the 2.4.40 changelog, I saw "Fixed ldapc++ memory leak in Async connection (ITS#7806)". The code change is at openldap-2.4.40/contrib/ldapc++/src/LDAPAsynConnection.cpp -Del- 46 LPAsysynConnection::~LDAPAsynConnection(){} +Add+ 46 LDAPAsynConnection::~LDAPAsynConnection(){ +Add+ 47 unbind(); +Add+ 48 delete m_constr; +Add+ 49 } But this caused a segV #0 0x00c40a79 in __gnu_cxx::__exchange_and_add(int volatile*, int) () from /usr/lib/libstdc++.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.5.i686 libgcc-4.4.7-11.el6.i686 libstdc++-4.4.7-11.el6.i686 (gdb) bt #0 0x00c40a79 in __gnu_cxx::__exchange_and_add(int volatile*, int) (9 9 from /usr/lib/libstdc++.so.6 #1 0x005e05c1 in ::~LDAPCtrl() () from /opt/LU3P/lib/libldapcpp.so.0 #2 0x005e0c7f in LDAPControlSet::~LDAPControlSet() () from /opt/LU3P/lib/libldapcpp.so.0 #3 0x005e02a3 in LDAPConstraints::~LDAPConstraints() () from /opt/LU3P/lib/libldapcpp.so.0 #4 0x005da82f in LDAPAsynConnection::~LDAPAsynConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #5 0x005dfa98 in LDAPConnection::~LDAPConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #6 0x005dfac2 in LDAPConnection::~LDAPConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #7 0x0805e189 in CpmLDAPOper::~CpmLDAPOper (this=0x82fc630, __in_chrg=<value optimized out>) at ../../../../../../glob/src/cpm_daemon/CpmLDAPOper.cpp:54 #8 0x0806486a in CpmMonMain::ReadFeatureOption (this=0x82fa228, force=1 '\001') at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:332 #9 0x08065c8c in CpmMonMain::CheckState (this=0x82fa228) at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:473 #10 0x08065ec0 in CpmMonMain::LoopWork (this=0x82fa228) at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:256 #11 0x0805348a in CpmMainBase::Run (this=0x82fa228, argc=1, argv=0xffcbe944) at ../../../../../../glob/src/cpm_daemon/CpmMainBase.cpp:156 #12 0x0806435d in main (argc=1, argv=0xffcbe944) at ../..F.F../../../../glob/src/cpm_daemon/CpmMonMain.cpp:517 (gdb) q Thanks, Jianying

1 0

(ITS#8142) back-ldap transparent reconnecting is not so transparent
by ebackes＠symas.com 13 May '15

13 May '15

Full_Name: Emily Backes Version: 2.4 OS: URL: Submission from: (NULL) (50.113.67.84) Currently, back-ldap stores credentials in the outbound connection structure. When that disappears, e.g. from idle-timeout, conn-ttl, network lossage, AD trouble, etc., the connection becomes unbound and AD returns err=1 (Operations error), which isn't enougfofor back-ldap to treat it as LDAP_UNAVAILABLE. Howard reports this is working-as-designed, even if the design is bad. Several ITS filings are still open about this problem; 5110, 6571, and 7464 are all related. At a minimum, we should drop the client connection if we can't keep the session stable. If we keep it open, we need to ensure we can precisely duplicate the client session-state, including credentials. (this would be very useful).

1 0

Re: (ITS#8140) ssf is hard coded to log as zero, even if it is non-zero
by quanah＠zimbra.com 12 May '15

12 May '15

--On Tuesday, May 12, 2015 1:18 PM +0000 hyc(a)symas.com wrote: > Works as designed. The Bind op itself didn't provide any security, so it > contributed 0 to the session's ssf. The preceding StartTLS request > actually established a security layer, and it correctly logs the ssf > from that. I think overall the design is problematic. "ssf" is generally supposed to indicate the overall security of the connection, regardless of the step. Perhaps for 2.5 and later, we could modify the logging line to be something more like: May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=256 So that the overall SSF of the connection is reflected, and we're indicating that specifically the BIND op added nothing to SSF. This would be useful for ldapi:/// connections as well, as there are zero ssf indicators logged at all outside of the bind op: May 12 02:30:19 ldap01 slapd[33839]: conn=169357 fd=85 ACCEPT from PATH=/opt/zimbra/data/ldap/state/run/ldapi (PATH=/opt/zimbra/data/ldap/state/run/ldapi) May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 RESULT tag=97 err=0 text= Even though I have: olcLocalSSF: 128 in my config DB I.e., I think it would be better to show: May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=128 in this case. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8141) Weird info returned by mdb_stat
by hyc＠symas.com 12 May '15

12 May '15

elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.38 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.163.84.201) > > > When running mdb_stat on some existing database, we get some results like : > > Status of className > Tree depth: 1 > Branch pages: 0 > Leaf pages: 1 > Overflow pages: 0 > Entries: 72899 > > I wonder how possibly we could have 72 899 entries stored into one single 4kb > page. You're looking at an index DB which uses sorted duplicates. The space used by the duplicates is in a subtree and the stats for that subtree aren't available. -- -- 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#8141) Weird info returned by mdb_stat
by elecharny＠apache.org 12 May '15

12 May '15

Full_Name: Emmanuel Lecharny Version: 2.4.38 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.163.84.201) When running mdb_stat on some existing database, we get some results like : Status of className Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 72899 I wonder how possibly we could have 72 899 entries stored into one single 4kb page.

1 0

Re: (ITS#8140) ssf is hard coded to log as zero, even if it is non-zero
by hyc＠symas.com 12 May '15

12 May '15

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.52.177) > > > bind.c hard codes the output of the ssf= line in some of the stats logging to be > zero, even if the connection actually has a higher ssf. For example: Works as designed. The Bind op itself didn't provide any security, so it contributed 0 to the session's ssf. The preceding StartTLS request actually established a security layer, and it correctly logs the ssf from that. Closing this ITS. > > May 11 02:28:06 ldap01 slapd[33839]: conn=153267 fd=86 TLS established > tls_ssf=256 ssf=256 tls_proto=TLSv1 tls_cipher=AES256-SHA > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" method=128 > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0%%0 > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 RESULT tag=97 err=0 text= > > > Note how we have mech=SIMPLE, ssf=0 > > Since we ran startTLS, and it was established, we clearly do NOT have an ssf of > zero. the ssf=0 bit is *hard coded* in bind.c in the fe_op_bind_success > function: > > /* log authorization identity */ > Statslog( LDAP_DEBUG_STATS, > "%s BIND dn=\"%s\" mech=%s ssf=0\n", > op->o_log_prefix, > op->o_conn->c_dn.bv_val, op->orb_mech.bv_val, 0, 0 ); > > > There's a similar block in do_bind for anonymous binds as well: > > if ( !BER_BVISEMPTY( &op->o_conn->c_dn ) ) { > /* log authorization identity demotion */ > Statslog( LDAP_DEBUG_STATS, > "%s BIND anonymous mech=implicit ssf=0\n", > op->o_log_prefix, 0, 0, 0, 0 ); > } > > It likely should be changed to use: > > op->o_conn->c_ssf > > > -- -- 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#8140) ssf is hard coded to log as zero, even if it is non-zero
by quanah＠openldap.org 11 May '15

11 May '15

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) bind.c hard codes the output of the ssf= line in some of the stats logging to be zero, even if the connection actually has a higher ssf. For example: May 11 02:28:06 ldap01 slapd[33839]: conn=153267 fd=86 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1 tls_cipher=AES256-SHA May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0%%0 May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 RESULT tag=97 err=0 text= Note how we have mech=SIMPLE, ssf=0 Since we ran startTLS, and it was established, we clearly do NOT have an ssf of zero. the ssf=0 bit is *hard coded* in bind.c in the fe_op_bind_success function: /* log authorization identity */ Statslog( LDAP_DEBUG_STATS, "%s BIND dn=\"%s\" mech=%s ssf=0\n", op->o_log_prefix, op->o_conn->c_dn.bv_val, op->orb_mech.bv_val, 0, 0 ); There's a similar block in do_bind for anonymous binds as well: if ( !BER_BVISEMPTY( &op->o_conn->c_dn ) ) { /* log authorization identity demotion */ Statslog( LDAP_DEBUG_STATS, "%s BIND anonymous mech=implicit ssf=0\n", op->o_log_prefix, 0, 0, 0, 0 ); } It likely should be changed to use: op->o_conn->c_ssf

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com 11 May '15

11 May '15

--On Monday, May 11, 2015 7:32 PM +0000 quanah(a)zimbra.com wrote: > The existing entry drift seems to be related to the locked up replication > that occured because of a bug in openssl. So the real issue is just the > entries that weren't created, which is a current known limitation of > syncrepl refresh that needs fixing. Howard suggests that at least in the delta-syncrepl case, we can modify syncprov to use the accesslog as the memory for its syncprov session log rather than the session log used with standard syncrepl. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8138) regarding some issues with SIDs
by quanah＠zimbra.com 11 May '15

11 May '15

--On Monday, May 11, 2015 8:35 AM +0000 nehadixit89(a)gmail.com wrote: > Full_Name: neha dixit > Version: 2.3 OpenLDAP 2.3 is not a supported piece of software. This ITS will be closed. In addition, the ITS system is for reporting bugs, not general usage questions. Please upgrade to a supported OpenLDAP release, and if you have questions, follow up on the openldap-technical mailing list. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

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