openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#8145) The olcThreadQueues config element is not documented
by elecharny＠gmail.com 15 May '15

15 May '15

Le 15/05/15 13:40, Howard Chu a écrit : > elecharny(a)apache.org wrote: >> Full_Name: Emmanuel L.charny >> Version: 2.4.40 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.202.0.248) >> >> >> The olcThreadQueues AttributeType is part of the olcGlobal >> OvjectClass since >> 2.4.36, where it's has been added. >> A man slapd-config provides no information on this parameter. > > You're mistaken. The olcThreadQueues feature has not been included in > any official 2.4 release, it is a 2.5 feature. > Sadly, I can't comment on an ITS. So here it is : "It may not be official, but it's present in the code base since 2.4.36, it's also present as a MAY attribute in the olcGlobal ObjectClass. There is no way for me to know that it's a 2.5 feature, if it's in 2.4 branch, and if it's not documented as so. This is not really convenient, as I'm basing the OpenLDAP configuration editor on the content of the existing ObjectClasses. You migth object that the reference is what's in the man page, but then, how possibly can we detect missing parts in the documentation?"

1 0

Re: (ITS#8145) The olcThreadQueues config element is not documented
by hyc＠symas.com 15 May '15

15 May '15

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.40 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.202.0.248) > > > The olcThreadQueues AttributeType is part of the olcGlobal OvjectClass since > 2.4.36, where it's has been added. > A man slapd-config provides no information on this parameter. You're mistaken. The olcThreadQueues feature has not been included in any official 2.4 release, it is a 2.5 feature. -- -- 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#8145) The olcThreadQueues config element is not documented
by elecharny＠apache.org 14 May '15

14 May '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.202.0.248) The olcThreadQueues AttributeType is part of the olcGlobal OvjectClass since 2.4.36, where it's has been added. A man slapd-config provides no information on this parameter.

1 0

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

14 May '15

--On Tuesday, May 12, 2015 7:58 PM +0000 quanah(a)zimbra.com wrote: > --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. Per Howard: we should update the SASL Bind log to use bind_ssf= as well --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7806) memory leak in contrib/ldapc++/LDAPAsynConnection.cpp
by quanah＠zimbra.com 14 May '15

14 May '15

--On Wednesday, February 26, 2014 6:15 PM +0000 kevpatt(a)khptech.com wrote: > Full_Name: Kevin H. Patterson > Version: git master HEAD > OS: macosx 10.9.1 > URL: > http://campus.hartland.edu/temp/0001-fixed-memory-leak-in-LDAPAsynConnect > ion.cpp.patch Submission from: (NULL) (65.207.4.130) > > > In libldapcpp, there is a memory leak in the LDAPAsynConnection class. > ldap_initialize() allocates memory which is never freed. This memory (ld > structure) should be freed by a call to ldap_unbind() in the class > destructor and other places where the ld structure is replaced with a new > one. > > I have included a patch against git master HEAD below. According to a ldap c++ user, this patch causes code to segv. Please see <https://www.openldap.org/its/private.cgi/?findid=8143> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8144) 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.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 12 May '15

12 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

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