openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8057) slapo-unique can be bypassed by anyone
by quanah＠zimbra.com 06 Apr '15

06 Apr '15

--On Saturday, February 14, 2015 6:16 PM +0000 ondra(a)mistotebe.net wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: > URL: > ftp://ftp.openldap.org/pub/Ondrej-Kuznik-20150214-ITS-8057-uniqueness-ACL > .patch Submission from: (NULL) (86.177.93.243) > > > This is caused by my fix for #6641. Since anyone can specify the > manageDSAit control on an operation it is trivial to bypass the > uniqueness check as it stands. This "fix" causes OpenLDAP to crash during replication: <http://fpaste.org/207817/70741142/> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8097) update nssov to nss-pam-ldapd 0.9.4
by ryan＠nardis.ca 05 Apr '15

05 Apr '15

Full_Name: Ryan Tandy Version: master, 2.4 OS: Debian URL: Submission from: (NULL) (24.68.37.4) updating the copied nss-pam-ldapd files: ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-nss-pam-ldapd-… updating nssov for those changes, see commit msg for details: ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-to-protocol-ve… while I'm in the code anyway, cleaning up a few compiler warnings (that were already there, I didn't introduce them :P). Cosmetic stuff: unused variables, return-type (void/non-void) mismatches, a couple of undeclared prototypes. ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-clean-up-some-compile… Please note, the protocol change breaks backwards compat with older versions of the client libraries (per nss-pam-ldapd/README). Tested on Linux. No idea about Solaris etc, sorry. The DN field was removed from the pam protocol, so uid lookup happens on every connection now. I couldn't think of a safe way to avoid that; suggestions welcome. -- (the following statements apply to patches 2 and 3 only; patch 1 is copied from work by Arthur de Jong, licensed LGPLv2.1) The attached patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the preceding patches were developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or interest in this work to any party. I, Ryan Tandy, hereby place the preceding modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8087) Segmentation fault in MDB at idl.c:91 using searches
by hyc＠symas.com 04 Apr '15

04 Apr '15

francisco(a)garnelo.eu wrote: > Full_Name: Francisco Garnelo > Version: slapd 2.4.40 > OS: FreeBSD 10.1-STABLE > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.21) Thanks for the report. Pretty sure this has already been fixed in RE24 for 2.4.41. Can you please test with the 2.4 release engineering branch and confirm whether the problem is still present? > > > > Hi, when I try to access with a LDAP browser (Apache DS) and the browser begin > to enumerate the items in differents branches, the server crashes; this not > takes more than 30 seconds from last restart. > > I experimented a similar issue with SLES 12(if not it is the same) and openldap > 2.4.40 (from suse repositories) version, but in this system I could not take > evidences. > > The database has more than 3GB of size and MDB is configured to support 100GB as > the maximum size. > > The same databa w works fine ining BDB using an old openldap version. > > ############# > # Versions: # > ############# > > root@XXXX:/usr/local/etc/openldap # /usr/local/libexec/slapd -VVV > @(#) $OpenLDAP: slapd 2.4.40 (Mar 24 2015 17:18:46) $ > root@XXXX:/usr/rtrts/net/openldap24-server/work/openldap-2.4.40/servers/slapd > > Included static overlays: > dynlist > seqmod > syncprov > Included static backends: > config > ldif > relay > > root@xxxx:/usr/local/etc/openldap # uname -a > FreeBSD xxxx 10.1-STABLE FreeBSD 10.1-STABLE #0 r278906: Tue Feb 17 19:09:13 UTC > 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > > > ###################### > # cn=config export: # > ###################### > > version: 1 > > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /var/run/openldap/slapd.args > olcAttributeOptions: lang- > olcAuthzPolicy: none > olcConfigDir: slapd.d > olcConfigFile: slapd.conf > olcIdleTimeout: 0 > olcIndexIntLen: 8 > olcIndexSubstrAnyLen: 4 > olcIndexSubstrAnyStep: 2 > olcIndexSubstrIfMaxLen: 4 > olcIndexSubstrIfMinLen: 2 > olcListenerThreads: 1 > olcLocalSSF: 71 > olcLogLevel: 0 > olcPidFile: /var/run/openldap/slapd.pid > olcReadOnly: FALSE > olcReverseLookup: FALSE > olcSizeLimit: unlimited > olcThreads: 20 > olcTLSCACertificateFile: /usr/local/etc/openldap/certs/public/ca.crt > olcTLSCertificateFile: /usr/local/etc/openldap/certs/public/server.crt > olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/private/server.key > olcTLSCRLCheck: none > olcTLSProtocolMin: 0.0 > olcTLSVerifyClient: never > olcToolThreads: 2 > olcWriteTimeout: 0 > > dn: cn=module{0},cn=config > objectClass: olcModuleList > cn: module{0} > olcModuleLoad: {0}back_mdb database config > olcModulePath: /usr/local/libexec/openldap > > dn: cn=schema,cn=config > objectClass: olcSchemaConfig > cn: schema > > ### -- omitted content -- ### > > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /r%r/local/etc/openldap/schema/rfc2307bis.schema > > ### -- omitted content -- ### > > > dn: olcDatabase={-1}frontend,cn=config > objectClass: olcFrontendConfig > objectClass: olcDatabaseConfig > olcDatabase: {-1}frontend > olcAccess: {0}to dn.base="" by * read > olcAccess: {1}to dn.base%%2"cn=subsemema" by * read > olcAccess: {2}to attrs=shadowLastChange by self write by * read > olcAccess: {3}to * by * read > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 0 > olcMonitoring: FALSE > olcReadOnly: FALSE > olcSchemaDN: cn=Subschema > olcSizeLimit: unlimited > olcSyncUseSubentry: FALSE > > dn: olcDatabase={0}config,cn=config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcAccess: {0}to * by * none > olcAddContentAcl: TRUE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcMonitoring: FALSE > olcReadOnly: FALSE > olcRootDN: cn=config > olcRootPW: XXXXX > olcSyncUseSubentry: FALSE > > dn: olcDatabase={1}mdb,cn=config > objectClass: olcMdbConfig > objectClass: olcDatabaseConfig > olcDatabase: {1}mdb > olcDbDirectory:2F2Fvar/db/openldap-data.mdb > olcDbIndex: objectClass eq > olcRootDN: cn=lalala,dc=yyyyyyy,dc=com > olcRootPW: XXXXXXX > olcSuffix: dc=yyyyyyy,dc=com > > > ######## > # GDB: # > ######## > > 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,%3=com") > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_dn2id: got id=0x92b0 > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 mdb_dn2entry("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_dn2id: got id=0x92b0 > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 <=dbdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 mdb_dn2entry("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 => mdb_dn2id("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 <= mdb_dn2id: got id=0x931e > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 <= mdb_entry_decode > 551194b7 daemon: activity on 1 descriptor > 551194b8 daemon: activity on:519194b8 11r551194b8 > 551194b8 daemon: read activity on 11 > 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b7 => mdb_entry_decode: > 551194b7 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 <= mdb_dn2id: got id=0x9321 > 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") > 551194b8 => mdb_entry_decode: > 551194b8 => mdb_dn2id("loloId=50,ou=fry,dc=yyyyyyy,dc=com") > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 daemon: select: listen=6 active_threads=0 tvp=NULL > 551194b8 daemon: select: listen=7 active_threads=0 tvp=NULL > 551194b8 <= mdb_dn2id: got id=0xf > 551194b6 <= mdb_entry_decode > 551194b8 => mdb_entry_dece:3A > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 <= mdb_entry_decode > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 <= mdb_entry_decode > 551194b8 mdb_dn2entry("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_dn2id: got id=0x9321 > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_dn2id("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 <= mdb_dn2id: got id=0x25 > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") > 551194b8 <= mdb_entry_decode > [New Thread 2103c12400 (LWP 100750/slapd)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 2103c12400 (LWP 100750/slapd)] > 0x00000008024a579f in mdb_idl_search (ids=0x210a980000, id=37) at idl.c:91 > 91 val = IDL_CMP( id, ids[cursor] ); > Current language: auto; currently minimal > > -------------- > > Thanks, Francisco Garnelo > > > -- -- 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#8086) slapd with mdb backend crashes in id2entry
by hyc＠symas.com 04 Apr '15

04 Apr '15

Nikos Voutsinas wrote: > I haven't compared the same build with and with out the fixes for > ITS#7961,#7987, however I can confirm that under the same environment, > RE24 (scheduled for 2.4.41) remains stable while 2.4.40 crashes from > time to time. Actually I would strongly suggest upgrading to 2.4.41 when > available. Thanks for the confirmation, we'll resolve this ITS. > > On Sun, Mar 22, 2015 at 9:36 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > Nikos Voutsinas wrote: > > I am in the process of doing so. Do you have in mind a specific > commit/fix in REL_EN that might have solved this; That would help me > reproduce the initial problem (in 2.4.40) and confirm the fix > (in REL_ENG). > > > Most likely 9a72292ac134f80c1befe8102dee11__60e57a92ec > > > For start I will try to upgrade to REL_ENG the same system from > which I > got the debug log, to see if that would help recover (although I > have no > great hopes). > > On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com> > <mailto:hyc@symas.com <mailto:hyc@symas.com>>> wrote: > > nvoutsin(a)gmail.com <mailto:nvoutsin@gmail.com> > <mailto:nvoutsin@gmail.com <mailto:nvoutsin@gmail.com>> wrote: > > Full_Name: Nikos Voutsinas > Version: 2.4.40 > OS: Debian > URL: > ftp://ftp.openldap.org/____incoming/NikosVoutsinas_20-03-____2015_mdb_asser… > <ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_assertion…> > > <ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_assertion… > <ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assertion.id2…>> > Submission from: (NULL) (5.55.167.101) > > > slapd with an mdb backend, after some time of normal > operation, > may reach into a > situation where you can almost predictably crash it, with a > simple modify > operation. > > > Please test RE24 and see if you can still reproduce this 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/ > <http://www.openldap.org/__project/> > <http://www.openldap.org/__project/ > <http://www.openldap.org/project/>> > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/__project/ > <http://www.openldap.org/project/> > > -- -- 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#8086) slapd with mdb backend crashes in id2entry
by nvoutsin＠gmail.com 04 Apr '15

04 Apr '15

--001a113513b628687b0512e2d415 Content-Type: text/plain; charset=UTF-8 I haven't compared the same build with and with out the fixes for ITS#7961,#7987, however I can confirm that under the same environment, RE24 (scheduled for 2.4.41) remains stable while 2.4.40 crashes from time to time. Actually I would strongly suggest upgrading to 2.4.41 when available. On Sun, Mar 22, 2015 at 9:36 PM, Howard Chu <hyc(a)symas.com> wrote: > Nikos Voutsinas wrote: > >> I am in the process of doing so. Do you have in mind a specific >> commit/fix in REL_EN that might have solved this; That would help me >> reproduce the initial problem (in 2.4.40) and confirm the fix (in >> REL_ENG). >> > > Most likely 9a72292ac134f80c1befe8102dee1160e57a92ec > >> >> For start I will try to upgrade to REL_ENG the same system from which I >> got the debug log, to see if that would help recover (although I have no >> great hopes). >> >> On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <hyc(a)symas.com >> <mailto:hyc@symas.com>> wrote: >> >> nvoutsin(a)gmail.com <mailto:nvoutsin@gmail.com> wrote: >> >> Full_Name: Nikos Voutsinas >> Version: 2.4.40 >> OS: Debian >> URL: >> ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03- >> __2015_mdb_assertion.id2entry >> <ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03- >> 2015_mdb_assertion.id2entry> >> Submission from: (NULL) (5.55.167.101) >> >> >> slapd with an mdb backend, after some time of normal operation, >> may reach into a >> situation where you can almost predictably crash it, with a >> simple modify >> operation. >> >> >> Please test RE24 and see if you can still reproduce this 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/ >> <http://www.openldap.org/project/> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a113513b628687b0512e2d415 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I haven't compared the same build with and with out th= e fixes for ITS#7961,#7987, however I can confirm that under the same envir= onment, RE24 (scheduled for 2.4.41) remains stable while 2.4.40 crashes fro= m time to time. Actually I would strongly suggest upgrading to 2.4.41 when = available. </div><div class=3D"gmail_extra"> <div class=3D"gmail_quot= e">On Sun, Mar 22, 2015 at 9:36 PM, Howard Chu <<a hre= f=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>> w= rote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex">Nikos Voutsinas wr= ote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I am in the process of doing so. Do you have in mind a specific commit/fix in REL_EN that might have solved this; That would help me reproduce the initial problem (in 2.4.40) and confirm the fix (in REL_ENG).= </blockquote> Most likely 9a72292ac134f80c1befe8102dee1160e57a92ec <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> For start I will try to upgrade to REL_ENG the same system from which I got the debug log, to see if that would help recover (although I have no<br= > great hopes). On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <<a href=3D"mailto:hyc@syma= s.com" target=3D"_blank">hyc(a)symas.com</a> <mailto:<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com= </a>>> wrote: =C2=A0 =C2=A0 <a href=3D"mailto:nvoutsin@gmail.com" target=3D"_blank">nvout= sin(a)gmail.com</a> <mailto:<a href=3D"mailto:nvoutsin@gmail.com" target= =3D"_blank">nvoutsin(a)gmail.com</a>> wrote: =C2=A0 =C2=A0 =C2=A0 =C2=A0 Full_Name: Nikos Voutsinas =C2=A0 =C2=A0 =C2=A0 =C2=A0 Version: 2.4.40 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OS: Debian =C2=A0 =C2=A0 =C2=A0 =C2=A0 URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"ftp://ftp.openldap.org/__incoming/Ni= kosVoutsinas_20-03-__2015_mdb_assertion.id2entry" target=3D"_blank">ftp://f= tp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_as= sertion.id2entry</a> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"ftp://ftp.openldap.org/incoming/= NikosVoutsinas_20-03-2015_mdb_assertion.id2entry" target=3D"_blank">ftp://f= tp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assert= ion.id2entry</a>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Submission from: (NULL) (5.55.167.101) =C2=A0 =C2=A0 =C2=A0 =C2=A0 slapd with an mdb backend, after some time of n= ormal operation, =C2=A0 =C2=A0 =C2=A0 =C2=A0 may reach into a =C2=A0 =C2=A0 =C2=A0 =C2=A0 situation where you can almost predictably cras= h it, with a =C2=A0 =C2=A0 =C2=A0 =C2=A0 simple modify =C2=A0 =C2=A0 =C2=A0 =C2=A0 operation. =C2=A0 =C2=A0 Please test RE24 and see if you can still reproduce this issu= e. =C2=A0 =C2=A0 -- =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Howard Chu =C2=A0 =C2=A0 =C2=A0 =C2=A0CTO, Symas Corp. <a href=3D"http://www.symas.com= " target=3D"_blank">http://www.symas.com</a> =C2=A0 =C2=A0 =C2=A0 =C2=A0Director, Highland Sun <a href=3D"http://highlan= dsun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 =C2=A0 =C2=A0 =C2=A0Chief Architect, OpenLDAP <a href=3D"http://www.= openldap.org/__project/" target=3D"_blank">http://www.openldap.org/__</u= >project/</a> =C2=A0 =C2=A0 <<a href=3D"http://www.openldap.org/project/" target=3D"_b= lank">http://www.openldap.org/project/</a>> </blockquote><div class=3D"HOEnZb"><div class=3D"h5"> -- =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </div></div></blockquote></div> </div> --001a113513b628687b0512e2d415--

1 0

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by quanah＠zimbra.com 03 Apr '15

03 Apr '15

--On Saturday, April 04, 2015 1:03 AM +0300 Leonid Yuriev <leo(a)yuriev.ru> wrote: > I had saw a queer in the CHANGES of 2.4 branch, and also comment of > aecec6a75. > > Exactly: Fixed slapo-syncprov deadlock when autogroup is in use > (ITS#8063,ITS#8081) > > But really, this (ITS#8081) is NOT related to autogroup (ITS#8063). > This bug was introduced by 7561998f7 (ITS#6335, Quanah Gibson-Mount > <quanah(a)openldap.org>, 2009-10-30). ITS#6335 was introduced in OpenLDAP 2.4.20. So wouldn't this then affect all releases since 2.4.20? Just so I can note that. ;) Also 6335 was not introduced by me. I simply sync'd it from master to RE24. ;) commit 739f8d075394ee3e85c3f2de7aa4031b36f54c8f Author: Rein Tollevik <rein(a)openldap.org> Date: Fri Oct 16 17:27:18 2009 +0000 ITS#6335 Don't reuse a modtarget someone is about to remove --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by leo＠yuriev.ru 03 Apr '15

03 Apr '15

I had saw a queer in the CHANGES of 2.4 branch, and also comment of aecec6a75. Exactly: Fixed slapo-syncprov deadlock when autogroup is in use (ITS#8063,ITS#8081) But really, this (ITS#8081) is NOT related to autogroup (ITS#8063). This bug was introduced by 7561998f7 (ITS#6335, Quanah Gibson-Mount <quanah(a)openldap.org>, 2009-10-30). Yes, after ITS#8063 this bug could be seen as SIGSEGV. But before ITS#8063 the syncprov could `re-order` notifications of changes that are visible by a remote syncrepl. Under a highload (our use case) this makes possible to 'lost' a some changes by replication, and then spread this error to all nodes of ldap-cluster (I spent a lot of time to dig this). So, this is a INDEPENDENT (critical) bug in syncprov (not in autogroup), which is also present in 2.4.40 release and so on.

1 0

Re: (ITS#8090) libldap bugfix: Spurious initial LDAP_CONNECT_ERROR with LDAP_OPT_CONNECT_ASYNC enabled
by hyc＠symas.com 01 Apr '15

01 Apr '15

olli.salli(a)vincit.fi wrote: > Full_Name: Olli Salli > Version: git master > OS: Windows 8.1, Linux 3.18.10 > URL: ftp://ftp.openldap.org/incoming/olli-salli-150325.patch > Submission from: (NULL) (83.102.45.242) Thanks for the report, fixed now in master. > > We are working on an application which needs to perform some simple LDAP search > queries every once in a while. The application is running as a daemon in an > embedded server environment and has no user interface, and is instead remotely > controlled and configured via a control TCP connection. This includes the > configuration specifying the LDAP server address and port, and whether the LDAP > queries should be attempted at all (if there is no server available). We are > currently developing on Windows 8.1 with Visual Studio 2013 but will also run in > Linux environments. > > To ensure the control TCP connection stays alive at all times (and the daemon > otherwise functional), and to avoid using threads, whahave used the openldap > asynchronous APIs, including the asynchronous connect option - if the configured > LDAP server is unreachable, the initial search query can block for a very long > time otherwise. It is here that we have hit a small issue. > > When using LDAP_OPT_CONNECT_ASYNC, if the LDAP server is unreachable, the > initial request (e.g. using ldap_search_ext) does not block, which is correct. > However, this first call returns LDAP_CONNECT_ERROR. If we disregard this, and > continue reissuing the ldap_search_ext request periodically, following calls > correctly return LDAP_X_CONNECTING. Then when the NETWORK_TIMEOUT has elapsed, > LDAP_CONNECT_ERROR is returned again, which is correct. > > LDAP_CONNECT_ERROR might result in the first ldap_search_ext call from > legitimate error conditions in connect() even in asynchronous mode, for example > out-of-resource conditions (EADDRNOTAVAIL), or all local network interfaces > being down (ENETUNREACH), etc. These should be handled as fatal errors, but > would be impossible to distinguish from the false initial LDAP_CONNECT_ERROR > resulting from using LDAP_OPT_CONNECT_ASYNC. > > The issue seems to be in ldap_send_initial_request > (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/…). > > When async connect is enabled what happens during the first request is: > 1) sd is initialized to AC_SOCKET_INVALID > 2) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) is called to determine whether > there is already a connection, and to fetch its socket descriptor to sd > 3) as there is no connection, it returns -1 and sd stays AC_SOCKET_INVALID > 4) a new connection is formed using ldap_open_defconn() > 5) ldap_int_check_async_open( ld, sd ) is called, but sd is still > AC_SOCKET_INVALID, and thus the poll fails > 6) LDAP_CONNECT_ERROR is returned > > On successive calls, what happens is > 1) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) returns success and a valid > socket descriptor > 2) opening a new connection is skipped > 3) ldap_int_check_async_open( ld, sd ) is called this time with a valid socket > descriptor > 4) the poll works as intended > > A simple fix is to simply reissue ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) > after opening the connection. This fixes the first poll to return > LDAP_X_CONNECTING as intended. This is implemented in the patch at the URL. A > perhaps more semantically correct alternative could be to return the created > socket descriptor from ldap_open_defconn(). > > -- -- 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#8093) Error string for LDAP_X_CONNECTING is missing
by hyc＠symas.com 01 Apr '15

01 Apr '15

mikko.auvinen(a)vincit.fi wrote: > Full_Name: Mikko Auvinen > Version: git master > OS: Windows 8.1 > URL: ftp://ftp.openldap.org/incoming/mikko-auvinen-150326.patch > Submission from: (NULL) (83.102.45.242) > > > ldap_search_ext() returns LDAP_X_CONNECTING when async connect attempt is > ongoing. > > ldap_err2string() is missing an error string for LDAP_X_CONNECTING so it's > returning "Unknown API error". > > Here's a patch that fixes this. > > Thanks, committed to master. -- -- 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#8092) slapd crash with sasl auxprop and empty suffix
by hyc＠symas.com 01 Apr '15

01 Apr '15

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: master, 2.4 > OS: Debian > URL: > Submission from: (NULL) (24.68.37.4) > > > Based on a Debian bug report: https://bugs.debian.org/781162 > > ./configure --enable-spasswd > > cat > slapd.conf << EOF > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > database mdb > directory . > suffix "" > EOF > > slapadd -f slapd.conf << EOF > dn: dc=com > objectClass: domain > > dn: dc=example,dc=com > objectClass: domain > > dn: uid=test,dc=example,dc=com > objectClass: account > objectClass: simpleSecurityObject > userPassword: {SASL}test(a)EXAMPLE.COM > > EOF > > ldapwhoami -x -D uid=test,dc=example,dc=com > Enter LDAP Password: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffeebab700 (LWP 28815)] > __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 > 210 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory. > (gdb) bt > #0 __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 > #1 0x0000000000441689 in select_backend (dn=0x7fffeebaa1a8, noSubs=1) at > backend.c:704 > #2 0x000000000049c7c2 in slap_auxprop_lookup (glob_context=0x0, > sparams=0x7fffe0001cd0, flags=0, > user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at sasl.c:370 > #3 0x00007ffff7bc463b in _sasl_auxprop_lookup (sparams=0x7fffe0001cd0, > flags=flags@entry=0, > user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at ../../lib/auxprop.c:959 > #4 0x00007ffff7bc5467 in _sasl_auxprop_lookup_user_props > (oparams=0x7fffe0001330, flags=3, conn=0x7fffe0000ac0) > at ../../lib/canonusr.c:220 > #5 _sasl_canon_user_lookup (conn=conn@entry=0x7fffe0000ac0, > user=user@entry=0x7fffe0001460 "test(a)EXAMPLE.COM", > ulen=ulen@entry=0, flags=flags@entry=3, > oparams=oparams@entry=0x7fffe0001330) at ../../lib/canonusr.c:281 > #6 0x00007ffff7bc5d39 in auxprop_verify_password (conn=0x7fffe0000ac0, > userstr=0x7fffe0001460 "test(a)EXAMPLE.COM", > passwd=0x7fffe0002696 "asdf", service=<optimized out>, user_realm=<optimized > out>) at ../../lib/checkpw.c:159 > #7 0x00007ffff7bcee78 in _sasl_checkpass (conn=conn@entry=0x7fffe0000ac0, > user=0x7fffe0001460 "test(a)EXAMPLE.COM", > userlen=userlen@entry=16, pass=pass@entry=0x7fffe0002696 "asdf", > passlen=passlen@entry=4) > at ../../lib/server.c:1922 > #8 0x00007ffff7bd1e50 in sasl_checkpass (conn=0x7fffe0000ac0, user=<optimized > out>, userlen=16, > pas3D0x0x7fffe0002696 "asdf", passlen=4) at ../../lib/server.c:1989 > #9 0x000000000049e4db in chk_sasl (sc=0x8cac98, passwd=0x7fffeebaa8a0, > cred=0x7fffe0002700, text=0x7fffeebaaae0) > at sasl.c:990 > #10 0x0000000000535278 in lutil_passwd (passwd=0x7fffe0003188, > cred=0x7fffe0002700, schemes=0x0, text=0x7fffeebaaae0) > at passwd.c:327 > #11 0x0000000000474aa6 in slap_passwd_check (op=0x7fffe00026b0, > e=0x7fffe0002f28, a=0x7fffe0002fa8, > cred=0x7fffe0002700, text=0x7fffeebaaae0) at passwd.c:529 > #12 0x00000000005088e7 in mdb_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:120 > #13 0x00000000004584f6 in fe_op_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:383 > #14 0x0000000000457bb4 in do_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:205 > #15 0x000000000042f68a in connection_operation (ctx=0x7fffeebaabf0, > arg_v=0x7fffe00026b0) at connection.c:1134 > #16 0x000000000042fc3a in connection_read_thread (ctx=0x7fffeebaabf0, argv=0xc) > at connection.c:1280 > #17 0x00000000005401bf in ldap_int_thread_pool_wrapper (xpool=0x8b83c0) at > tpool.c:958 > #18 0x00007ffff74750a4 in start_thread (arg=0x7fffeebab700) at > pthread_create.c:309 > #19 0x00007ffff71aa04d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > > I don't know how auxprop is intended to be configured; I'm going to follow up on > that when I have time. This is just about a segv that happens when > pwcheck_method is auxprop (the default) and the suffix is the empty string. Fundamentally this is a configuration error; you should not use SPASSWD with slapd's auxprop. I.e., slapd's auxprop is only intended for use when slapd handles all SASL authentication itself. Using SPASSWD means you're forwarding all SASL authentication to whatever external SASL mechanisms you have configured. In this particular case, slapd has forwarded the authentication request out to libsasl as you requested, and libsasl is forwarding it back into slapd's auxprop but without providing the context that slapd expects. Fixed now in master. -- -- 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