openldap-bugs January 2016

openldap-bugs@openldap.org

22 participants
58 discussions

(ITS#8352) error 124 (exit status) from ldapsearch
by leo＠yuriev.ru 16 Jan '16

16 Jan '16

Full_Name: Leonid Yuriev Version: master OS: RHEL7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (31.130.36.33) While debugging on a server side I got 124 exit status from ldapseach. I guess that is something like a timeout condition. For instance, a timeout while waiting response from a LDAP-server. But return of the 124 seems a bug (in the ldap-library or ldapsearch), because such code was never defined or documented. Adding the '-v' (verbose) to ldapsearch options gives nothing of useful info, just only a "ldap_initialize(...)" string.

1 0

(ITS#8351) accesslog crashes slap_writewait_play
by hyc＠openldap.org 15 Jan '16

15 Jan '16

Full_Name: Howard Chu Version: 2.4.43 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.202) Submitted by: hyc There's an improperly initialized slap_callback that leaves garbage in the sc_writewait pointer. Fix coming shortly.

1 0

Re: (ITS#8350) lmdb SIGBUS error on full partition and possible double free issue
by hyc＠symas.com 14 Jan '16

14 Jan '16

> I'm not sure if this next one is an issue or just incorrect usage on my part. > So take with a grain of salt. > > After getting an EIO (deliberate out of storage space) from a mdb_txn_commit, > the transaction would be mdb_txn_abort()ed. I then would close then env which > would get a SIGABORT from a double-free on the env_close0 with env->txn0. The docs say quite clearly, after txn_commit the txn must not be used again. It has already been freed so you cannot use it with txn_abort. -- -- 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#8350) lmdb SIGBUS error on full partition and possible double free issue
by jeremiah.morrill＠econnect.tv 14 Jan '16

14 Jan '16

Full_Name: Jeremiah Morrill Version: 0.9 OS: Linux (Ubuntu14) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.173.183.164) Two possible issues. Semi-related. The first: On a full storage partition, when creating a new database, I get a SIGBUS. I believe it is caused by the locks successfully mmap()ing, but not really having the storage to back it. I hacked in a "posix_fallocate" to make sure the storage space is there and it appeared to fix it. I have no idea what the unintended consequences of this change may be. Here is the diff: void @@ -4863,6 +4868,14 @@ mdb_env_setup_locks(MDB_env *env, char *lpath, int mode, int *excl) void *m = mmap(NULL, rsize, PROT_READ|PROT_WRITE, MAP_SHARED, env->me_lfd, 0); if (m == MAP_FAILED) goto fail_errno; + + rc = posix_fallocate(env->me_lfd, 0, rsize); + + if (rc) { + munmap(m, rsize); + goto fail; + } + env->me_txns = m; #endif } I'm not sure if this next one is an issue or just incorrect usage on my part. So take with a grain of salt. After getting an EIO (deliberate out of storage space) from a mdb_txn_commit, the transaction would be mdb_txn_abort()ed. I then would close then env which would get a SIGABORT from a double-free on the env_close0 with env->txn0. The hack I put in there to avoid this was in the mdb_txn_end. I check if txn == env->me_txn0, and if it is, to set env->me_txn0 to NULL. Here's the diff: @@ -3244,12 +3244,17 @@ mdb_txn_end(MDB_txn *txn, unsigned mode) } pthread_mutex_unlock(&env->me_rpmutex); tl[0].mid = 0; - if (mode & MDB_END_FREE) + if (mode & MDB_END_FREE) free(tl); } #endif - if (mode & MDB_END_FREE) - free(txn); + if (mode & MDB_END_FREE) { + /* avoid double free on env close */ + if(txn == env->me_txn0){ + env->me_txn0 = NULL; + } + free(txn); + } }

1 0

ITS#8331
by hyc＠symas.com 13 Jan '16

13 Jan '16

I've removed the obsolete Netherlands listing and added this. -------- Forwarded Message -------- Subject: openldap public mirror in europe Date: Wed, 13 Jan 2016 08:22:02 +0100 From: Jakob-Tobias Winter <jakob-tobias.winter(a)1und1.de> To: hyc(a)symas.com CC: Michael Ströder <michael(a)stroeder.com> Howard, we set up a public mirror for your project based in Germany. It is mirrored via rsync and is reachable via: http://mirror.eu.oneandone.net/software/openldap/ Best regards Jakob -- Jakob-Tobias Winter Operations Manager IT Dedicated / Cloud / Virtual Server IT Operations WebPlatforms Server 1&1 Internet AG Ernst-Frey-Straße 9 DE-76135 Karlsruhe Telefon: +49 721 91374 4416 E-Mail: jakob-tobias.winter(a)1und1.de Web: www.1und1.de Amtsgericht Montabaur / HRB 6484 Vorstände: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Robert Hoffmann, Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen, Martin Witt, Christian Würst Aufsichtsratsvorsitzender: Michael Scheeren Member of United Internet

1 0

Re: (ITS#8349) fix ppolicy issue
by hamano＠osstech.co.jp 13 Jan '16

13 Jan '16

Hi, On Tue, 12 Jan 2016 17:46:23 +0900, Michael Ströder wrote: > > > 1) reduce pwdInHistory > > If set pwdInHistory to 5 then reduce pwdInHistory to 3, > > I try to rephrase: > If attribute 'pwdHistory' in the user entry has 5 values and attribute > 'pwdInHistory' in the policy entry is 3 then ignore (and remove?) the 2 oldest > 'pwdHistory' values. > Exactly! Thanks for your rephrase. > Are values in 'pwdInHistory' sorted by timestamp in this part of the code? > Ya, parsed pwdInHistory(pw_hist *tl) are sorted by ascending time order. So, In this case, we need ignore first 2 attributes then check 3 attributes. > > We expect to check password with three history, but ppolicy check > > password with all pwdHistory attribute. > > > > 2) reduce pwdInHistory to zero > > If set pwdInHistory to 5 then reduce pwdInHistory to 0, > > I try to rephrase: > If attribute 'pwdHistory' in the user entry is set and attribute 'pwdInHistory' > in the policy entry is 0 then ignore (and remove?) 'pwdHistory' completely. > > > We expect that ppolicy password checking will be disbale. but the > > pwdHistory attribute are remains, so password checking is still > > enabled. > > We need to remove pwdHistory attribute. > > I'm not sure whether removing 'pwdHistory' attribute (values) is the right thing > to do. If you want to increase 'pwdInHistory' later then the old values are lost. > Currently, pwdHistory attributes will truncate when to reduce 'pwdInHistory'. But this process is simply skipping when pwdInHistory: 0. this behavior is unnatural. I know how you feel. I'm sure root of issue is that 'pwdInHistory' attribute have both role "number of record pwdHistory" and "number of check pwdHistory". Thay are desirable to split same as 'pwdMaxFailure' and 'pwdMaxRecordedFailure'. Thank you. > Ciao, Michael. > -- Open Source Solution Technology Corporation HAMANO Tsukasa <hamano(a)osstech.co.jp> fingerprint = 3747 AB70 7B98 7882 46F5 87E1 BF91 A2C1 7DC1 5E3D

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by Johannes.Kanefendt＠krzn.de 13 Jan '16

13 Jan '16

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002C2E33C1257F39_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Michael Str=F6der <michael(a)stroeder.com> schrieb am 12.01.2016 20:13:15: > The whole purpose of using the Assertion Control is that it should match = the > modified entry. When I construct a filter deliberately not matching=20 > the entry I > can simply omit the Assertion Control completely. The logical outcome of the assertion doesn't change as the actual=20 assertion filter is or-ed with a rule that will never match the targeted=20 entry. However, when (wrongly) passed to unique=5Fsearch, it will prevent a= =20 failure as all other entries than the target match. >=20 > Maybe I didn't get your idea though. >=20 > The use-case: My web2ldap sends Assertion Control along with a modify=20 request > with a filter constructed from all attributes considered to be not=20 modified by > another user: >=20 > (&(entryCSN=3D20160112183104\2e449732Z\23000000\23000\23000000) > (creatorsName=3Dcn=3Dmichael\20str\c3\b6der\2bmail=3Dmichael@stroeder > \2ecom\2cou=3Dprivate\2cdc=3Dstroeder\2cdc=3Dde)(entryUUID=3D1c66859e\2d3= 441 > \2d1034\2d93db\2d751297a711ee)(modifiersName=3Dcn=3Dmichael\20str\c3 > \b6der\2bmail=3Dmichael@stroeder\2ecom\2cou=3Dprivate\2cdc=3Dstroeder > \2cdc=3Dde)(createTimestamp=3D20150119160811Z)(entryDN=3Dou=3Dtest > \2cou=3DTesting\2cdc=3Dstroeder\2cdc=3Dde)(modifyTimestamp=3D201601121831= 04Z)) >=20 Try to enclose the assertion by=20 (|(...)(!(entryDN=3Dou=3Dtest,ou=3DTesting,dc=3Dstroeder,dc=3Dde))) or=20 (|(...)(!(entryUUID=3D1c66859e-34411034-93db-751297a711ee))) --=_alternative 002C2E33C1257F39_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <tt>Michael Str=F6der <michael(a)stroeder.com> schrieb am 12.01.2016 20:13:15: > The whole purpose of using the Assertion Control is that it should match the > modified entry. When I construct a filter deliberately not matching > the entry I > can simply omit the Assertion Control completely.</tt> <tt>The logical outcome of the assertion doesn't change as the actual assertion filter is or-ed with a rule that will never match the targeted entry. However, when (wrongly) passed to unique=5Fsearch, it will prevent a failure as all other entries than the target match.</= tt> <tt> > > Maybe I didn't get your idea though. > > The use-case: My web2ldap sends Assertion Control along with a modify request > with a filter constructed from all attributes considered to be not modified by > another user: > > (&(entryCSN=3D20160112183104\2e449732Z\23000000\23000\23000000) > (creatorsName=3Dcn=3Dmichael\20str\c3\b6der\2bmail=3Dmichael@stroeder<= br> > \2ecom\2cou=3Dprivate\2cdc=3Dstroeder\2cdc=3Dde)(entryUUID=3D1c66859e\= 2d3441 > \2d1034\2d93db\2d751297a711ee)(modifiersName=3Dcn=3Dmichael\20str\c3<b= r> > \b6der\2bmail=3Dmichael@stroeder\2ecom\2cou=3Dprivate\2cdc=3Dstroeder<= br> > \2cdc=3Dde)(createTimestamp=3D20150119160811Z)(entryDN=3Dou=3Dtest > \2cou=3DTesting\2cdc=3Dstroeder\2cdc=3Dde)(modifyTimestamp=3D201601121= 83104Z)) > </tt> <tt>Try to enclose the assertion by (|(...)(!(entryDN=3D= ou=3Dtest,ou=3DTesting,dc=3Dstroeder,dc=3Dde))) or (|(...)(!(entryUUID=3D1c66859e-34411034-93db-751297a711ee))) </tt> --=_alternative 002C2E33C1257F39_=--

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by michael＠stroeder.com 12 Jan '16

12 Jan '16

Johannes.Kanefendt(a)krzn.de wrote: > A workaround is to extend the assertion filter to match all other entries > except the one to be modified: > > (|(cn=*)(!(entryDN=cn=Anna\20Blume,ou=Users,ou=schulung,dc=stroeder,dc=local))) The whole purpose of using the Assertion Control is that it should match the modified entry. When I construct a filter deliberately not matching the entry I can simply omit the Assertion Control completely. Maybe I didn't get your idea though. The use-case: My web2ldap sends Assertion Control along with a modify request with a filter constructed from all attributes considered to be not modified by another user: (&(entryCSN=20160112183104\2e449732Z\23000000\23000\23000000)(creatorsName=cn=michael\20str\c3\b6der\2bmail=michael@stroeder\2ecom\2cou=private\2cdc=stroeder\2cdc=de)(entryUUID=1c66859e\2d3441\2d1034\2d93db\2d751297a711ee)(modifiersName=cn=michael\20str\c3\b6der\2bmail=michael@stroeder\2ecom\2cou=private\2cdc=stroeder\2cdc=de)(createTimestamp=20150119160811Z)(entryDN=ou=test\2cou=Testing\2cdc=stroeder\2cdc=de)(modifyTimestamp=20160112183104Z)) This is done to really ensure that the entry was *not* changed after being read into the input form the user edits. Ciao, Michael.

1 0

Re: (ITS#6916) slapo-unique returns operations error when assertion control is used
by Johannes.Kanefendt＠krzn.de 12 Jan '16

12 Jan '16

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 0057F226C1257F38_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable A workaround is to extend the assertion filter to match all other entries=20 except the one to be modified: (|(cn=3D*)(!(entryDN=3Dcn=3DAnna=20 Blume,ou=3DUsers,ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal))) -- Mit freundlichem Gru=DF Im Auftrag Johannes Kanefendt Kommunales Rechenzentrum Niederrhein Der Verbandsvorsteher Abteilung 2.3.2 - Schulen Online Friedrich-Heinrich-Allee 130 47475 Kamp-Lintfort -Germany- Telefon: +49 (0)2842 90 70 125 Web: www.krzn.de Email: Johannes.Kanefendt(a)krzn.de --=_alternative 0057F226C1257F38_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable A workaround is to extend the assertion filter to match all other entries except the one to be modified: (|(cn=3D*)(!(entryDN=3Dcn=3DAnna Blu= me,ou=3DUsers,ou=3Dschulung,dc=3Dstroeder,dc=3Dlocal))) -- Mit freundlichem Gru=DF Im Auftrag Johannes Kanefendt Kommunales Rechenzentrum Niederrhein= Der Verbandsvorsteher Abteilung 2.3.2 - Schulen Online</fo= nt> Friedrich-Heinrich-Allee 130 47475 Kamp-Lintfort -Germany- Telefon: +49 (0)2842 90 70 125 Web: <a href=3Dwww.krzn.de><f= ont size=3D2 color=3Dblue face=3D"sans-serif">www.krzn.de</a> Email: Johannes.Kanefendt(a)krzn.de --=_alternative 0057F226C1257F38_=--

1 0

Re: (ITS#8296) slapd suddenly crash when using syncprov
by maurizio.lattuada＠gmail.com 12 Jan '16

12 Jan '16

Hello Quanah, only for information, were you able to reproduce this issue? Thanks for the feedback 2015-11-02 10:57 GMT+01:00 Maurizio Lattuada <maurizio.lattuada(a)gmail.com>: > Hello Quanah, > > unfortunately I cannot send here the complete and precise schema, is > used by our internal proprietary applications. > Anyway, it can be described as: > * dc=directory > ** ou=person > ** ou=organization > ** ou=relationship > > "ou=person" has "objectClass=inetOrgPerson" and an identifier (yeah, > clearly other fields like first name, last name, isActive, phone > number, address and so on) > "ou=organization" has an identifier plus the other "common" fields > (name, address...) > "ou=relationship" has "objectClass=groupOfNames" and is used to describe: > * relationships between persons and organizations ("a person belongs > to one or more organization", that is an "organization has these > persons as members") > * relationships between organizations (e.g. "org_1_a is a > sub-organization of the main organization org_1", that is "org_1 has > org_1_a as member"). > > So, considering the schema I described in my previous email: > > Test-bench_application --> spring_http_invoker --> Server_side_app > ---> data_for_db_2 ---> LDAP ---> data_from_db_2 ---> > App_in_syncprov_with_ldap > > the "Server_side_app" creates in sequence: > * one unique organization (let me call it simply "org_p", it has no > sub-organization) > * about 19500 persons by doing a loop as: > ** create one person > ** create the related entry in "ou=relationship" to describe "person > x belongs to org_p" > > Meanwhile this procedure is done, the synchronization via syncprov is > running to keep in sync the LDAP database 2 and > "App_in_syncprov_with_ldap". > > Hope it helps. > > thanks for the feedback. > > > > 2015-10-30 19:06 GMT+01:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: >> --On Friday, October 30, 2015 10:35 AM +0100 Maurizio Lattuada >> <maurizio.lattuada(a)gmail.com> wrote: >> >>> Hello Quanah, >>> >>> I added the syncprov overlay to the 1st database, but is neither used >>> by our application (rather than by another off-the-shelf application) >>> nor replicated as is for the 2nd database. >>> For your 2nd request, unfortunately I'm not able to test it, since >>> between the LDAP and my test-bench application there is another server >>> side application: >> >> >> Ok. Is it possible to provide the custom schema you are using, and an >> example of a user entry you are loading, so I can template it? I'd like to >> see if I can reproduce the problem. >> >> Thanks. >> >> >> --Quanah >> >> -- >> >> Quanah Gibson-Mount >> Platform Architect >> Zimbra, Inc. >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration > > > > -- > Maurizio Lattuada -- Maurizio Lattuada

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2016