- openldap-bugs - openldap.org

(ITS#8210) slapd-sock: second subsequent bind fails
by michael＠stroeder.com 01 Aug '15

01 Aug '15

Full_Name: Version: OS: URL: Submission from: (NULL) (79.223.48.67) When using *one* connection for sending *two* sequential bind requests slapd-sock blocks. I have a working test case which I can send upon request.

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by michael＠stroeder.com 01 Aug '15

01 Aug '15

IanB wrote: > I've attempted to test with OpenLDAP 2.4.41 but cannot get password changing > to work at all, constantly getting error: "passwd: Authentication token > manipulation error" Greping through the source this message is output from slapo-nssov. Are you sure that you re-built and installed slapo-nssov from 2.4.41? Also you should always first test with ldappasswd command-line tool to avoid false interaction with other software. What else do you have configured? > Unfortunately, I cannot spend more time on this now. What does that mean? If you don't want to work on this ITS any further it's probably the best to close it. Ciao, Michael.

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by porjo38＠yahoo.com.au 01 Aug '15

01 Aug '15

I've attempted to test with OpenLDAP 2.4.41 but cannot get password changing to work at all, constantly getting error: "passwd: Authentication token manipulation error" Unfortunately, I cannot spend more time on this now. On 30/07/15 03:01, Michael Ströder wrote: > porjo38(a)yahoo.com.au wrote: >> Using password policy overlay, pwdMinLength is not checked when pwdInHistory == >> 0. > > I tried to reproduce this with my local OpenLDAP 2.4.41 installation. > In one case I thought to see this but I could not reproduce all the time. > Maybe there's another condition for this to happen. > > Could you please also test with release 2.4.41? > > And please also post the entry with the password (and relevant pwd* attrs) and > the pwdPolicy entry used, both as LDIF (minus sensitive data). > > Ciao, Michael. >

1 0

Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
by hyc＠symas.com 30 Jul '15

30 Jul '15

juerg.bircher(a)helmedica.com wrote: > --_000_D1E06B6B7E2juergbircherhelmedicacom_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi Howard, > > I am new to lmdb. I have been working with lmdb intensively for one month. = > I really appreciate your great work. Good efficient C code is not always fo= > und! > Well I like to follow up on that reported issue. > I am using multiple databases on the same environment. I was a bit confused= > about your statement that most application use never subDBs? I think it is= > a great feature that helps to support multiple indexes. > I ran unintentionally into a related problem as I set the compare function = > for the main db to an integer based one opposite to the literal compare fun= > ction which is the default. Therefore when opening a database by its name t= > he wrong database might be returned as the integer compare function might t= > hink names are equal as only 96 bits (in my function) are compared. So the = > compare function only compares the prefix of the database names! > Maybe the database meta should be kept in a private space. But I also agree= > on your statement to keep things simple. I solved the problem by never usi= > ng the main db so under no circumstances the database meta is corrupted. I = > think the price paid for having only named databases is very cheap as I ope= > n databases at startup and keep the database index (dbi). Thanks for the feedback. Yes, this is the best practice - if you're using named databases, you should not use the main DB. (Or just make sure you don't create name collisions.) -- -- 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#8181) LMDB page leaks etc when treating DBs as data
by juerg.bircher＠helmedica.com 30 Jul '15

30 Jul '15

Sorry the mail before was not as plain text. Here again... Hi Howard, I am new to lmdb. I have been working with lmdb intensively for one month. I really appreciate your great work. Good efficient C code is not always found! Well I like to follow up on that reported issue. I am using multiple databases on the same environment. I was a bit confused about your statement that most application use never subDBs? I think it is a great feature that helps to support multiple indexes. I ran unintentionally into a related problem as I set the compare function for the main db to an integer based one opposite to the literal compare function which is the default. Therefore when opening a database by its name the wrong database might be returned as the integer compare function might think names are equal as only 96 bits (in my function) are compared. So the compare function only compares the prefix of the database names! Maybe the database meta should be kept in a private space. But I also agree on your statement to keep things simple. I solved the problem by never using the main db so under no circumstances the database meta is corrupted. I think the price paid for having only named databases is very cheap as I open databases at startup and keep the database index (dbi). Regards J=FCrg Rockethealth by Helmedica AG Web: www.rockethealth.ch J=FCrg Bircher Chief Technology Officer Mail: juerg.bircher(a)helmedica.ch

1 0

Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
by juerg.bircher＠helmedica.com 30 Jul '15

30 Jul '15

--_000_D1E06B6B7E2juergbircherhelmedicacom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Howard, I am new to lmdb. I have been working with lmdb intensively for one month. = I really appreciate your great work. Good efficient C code is not always fo= und! Well I like to follow up on that reported issue. I am using multiple databases on the same environment. I was a bit confused= about your statement that most application use never subDBs? I think it is= a great feature that helps to support multiple indexes. I ran unintentionally into a related problem as I set the compare function = for the main db to an integer based one opposite to the literal compare fun= ction which is the default. Therefore when opening a database by its name t= he wrong database might be returned as the integer compare function might t= hink names are equal as only 96 bits (in my function) are compared. So the = compare function only compares the prefix of the database names! Maybe the database meta should be kept in a private space. But I also agree= on your statement to keep things simple. I solved the problem by never usi= ng the main db so under no circumstances the database meta is corrupted. I = think the price paid for having only named databases is very cheap as I ope= n databases at startup and keep the database index (dbi). Regards J=FCrg Rockethealth by Helmedica AG Web: www.rockethealth.ch<http://www.rockethealth.ch/> J=FCrg Bircher Chief Technology Officer Mail: juerg.bircher(a)helmedica.ch<mailto:christoph.baumann@helmedica.ch> --_000_D1E06B6B7E2juergbircherhelmedicacom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <86943131EABB0349A4C3B75E01000508(a)eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <div>Hi Howard,</div> <div><br> </div> <div>I am new to lmdb. I have been working with lmdb intensively for one mo= nth. I really appreciate your great work. Good efficient C code is not alwa= ys found! </div> <div>Well I like to follow up on that reported issue.</div> <div>I am using multiple databases on the same environment. I was a bit con= fused about your statement that most application use never subDBs? I think = it is a great feature that helps to support multiple indexes. </div> <div>I ran unintentionally into a related problem as I set the compare func= tion for the main db to an integer based one opposite to the literal compar= e function which is the default. Therefore when opening a database by its n= ame the wrong database might be returned as the integer compare function might think names are equal as on= ly 96 bits (in my function) are compared. So the compare function only comp= ares the prefix of the database names!</div> <div>Maybe the database meta should be kept in a private space. But I also = agree on your statement to keep things simple. I solved the problem by neve= r using the main db so under no circumstances the database meta is corrupte= d. I think the price paid for having only named databases is very cheap as I open databases at startup and keep= the database index (dbi).</div> <div><br> </div> <div>Regards</div> <div>J=FCrg</div> <div><br> </div> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; = line-height: 11pt;"> <b><span lang=3D"EN-US" style=3D"font-size: 9pt; color: rgb(139, 141, 141);= font-family: 'FS Joey Medium';">Rockethealth by Helmedica AG<o:p></o:p></s= pan></b></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span lang=3D"EN-US" style=3D"font-size: 9pt; color: gray;">Web</span><spa= n lang=3D"EN-US" style=3D"font-size: 9pt; color: rgb(31, 73, 125);">: = </span><span style=3D"font-size: 9pt; color: rgb(31, 73, 125);"><a href=3D"= http://www.rockethealth.ch/" style=3D"color: rgb(149, 79, 114);"><span lang= =3D"EN-US" style=3D"color: blue;">www.rockethealth.ch</span></a></span><spa= n style=3D"font-size: 9pt; color: rgb(31, 73, 125);"></span><span lang=3D"E= N-US" style=3D"color: rgb(31, 73, 125);"><o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span lang=3D"EN-US" style=3D"font-size: 9pt; color: gray;">J=FCrg Bircher= </span></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span style=3D"color: gray; font-size: 9pt;">Chief Technology </span>= <span style=3D"color: rgb(128, 128, 128); font-size: 12px;">Officer</span><= /p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span lang=3D"EN-US" style=3D"font-size: 9pt; color: gray;">Mail: </s= pan><span style=3D"font-size: 9pt; color: rgb(31, 73, 125);"><a href=3D"mai= lto:christoph.baumann@helmedica.ch" style=3D"color: rgb(149, 79, 114);"><sp= an lang=3D"EN-US" style=3D"color: blue;">juerg.bircher(a)helmedica.ch</span><= /a></span><span lang=3D"EN-US" style=3D"color: rgb(31, 73, 125);"><o:p></o:= p></span></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span style=3D"color: gray; font-size: 11pt;"> </span><span style=3D"= font-size: 14px;"> </span></p> </body> </html> --_000_D1E06B6B7E2juergbircherhelmedicacom_--

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by porjo38＠yahoo.com.au 30 Jul '15

30 Jul '15

Thanks, I will try with 2.4.41 and let you know. I may not get a chance to test until this weekend. Relevant output from slapcat: dn: uid=ian,ou=UserAccounts,o=cwa objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: ldapPublicKey givenName: Ian displayName: Ian Bishop uid: ian homeDirectory: /home/ian loginShell: /bin/bash cn: Ian Bishop structuralObjectClass: inetOrgPerson entryUUID: 767c952c-c867-1034-933d-53d15af42765 creatorsName: cn=admin,o=cwa createTimestamp: 20150727045535Z gidNumber: 1000 sn: Bishop uidNumber: 10000 userPassword:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx pwdChangedTime: 20150729140556Z pwdHistory: 20150729140556Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}xxxxxxxxxx entryCSN: 20150729140556.659729Z#000000#000#000000 modifiersName: cn=admin,o=cwa modifyTimestamp: 20150729140556Z dn: cn=passwordDefault,ou=policies,o=cwa objectClass: pwdPolicy objectClass: person objectClass: top cn: passwordDefault sn: passwordDefault pwdAttribute: userPassword pwdCheckQuality: 0 pwdMinAge: 0 pwdMaxAge: 0 pwdMaxFailure: 3 pwdFailureCountInterval: 0 pwdLockout: TRUE pwdAllowUserChange: TRUE pwdExpireWarning: 0 pwdGraceAuthNLimit: 0 pwdMustChange: FALSE pwdSafeModify: TRUE structuralObjectClass: person entryUUID: 3314dc02-ca3f-1034-825a-9d42205b22be creatorsName: cn=config createTimestamp: 20150729131225Z pwdMinLength: 6 pwdLockoutDuration: 300 pwdInHistory: 1 entryCSN: 20150729135535.164545Z#000000#000#000000 modifiersName: cn=admin,o=cwa modifyTimestamp: 20150729135535Z On 30/07/15 03:01, Michael Ströder wrote: > porjo38(a)yahoo.com.au wrote: >> Using password policy overlay, pwdMinLength is not checked when pwdInHistory == >> 0. > > I tried to reproduce this with my local OpenLDAP 2.4.41 installation. > In one case I thought to see this but I could not reproduce all the time. > Maybe there's another condition for this to happen. > > Could you please also test with release 2.4.41? > > And please also post the entry with the password (and relevant pwd* attrs) and > the pwdPolicy entry used, both as LDIF (minus sensitive data). > > Ciao, Michael. >

1 0

Re: (ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 29 Jul '15

29 Jul '15

On 29/07/15 21:25, h.b.furuseth(a)usit.uio.no wrote: > (...)And copythr should set mc_new=0 before exiting also when setting > mc_status. so copyfd1 won't just sit and wait. I forgot it clears mc_new before setting mc_status. It's if it didn't keep the mutex it would have to set mc_new afterwards (after locking the mutex).

1 0

(ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 29 Jul '15

29 Jul '15

Full_Name: Hallvard B Furuseth Version: LMDB_0.9.15 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.191.45.5) Submitted by: hallvard mdb_env_copyfd1() and mdb_env_copythr() synchronize via my->mc_new, but incorrectly. copythr() starts before there is any data to consume, and copyfd1() does not tell it (by setting mc_new and signalling) when there is data. Instead it sets mc_new before it has finished producing the data. I suppose copythr just waits for a spurious wakeup, I haven't looked closely. It got it right originally when copyfd1 did not start the new thread until data (metapages) was ready. Or copyfd1 could start with mc_new = 0, and set it and signal when data is ready. copythr holds the mutex while writing. That's not how conds are supposed to be used. Threads are supposed to grab the mutex briefly around code which operates on mc_new. mc_status can be lost. Copyfd1 does not always use it, or it discards it. And copythr should set mc_new=0 before exiting also when setting mc_status. so copyfd1 won't just sit and wait.

1 0

Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
by michael＠stroeder.com 29 Jul '15

29 Jul '15

robert.brooks(a)reporo.com wrote: > with ppolicy overlay loaded (and functioning) the following root DSE is= : > [..] > I would expect to see output similar to... >=20 > http://docs.forgerock.org/en/opendj/2.6.0/dev-guide/index/chap-getting-= directory-info.html#read-root-dse > D0D > specifilllly line 12 (and maybe line 40). It's a bit hard to follow line number references in a web page. :-/ But I guess you mean the OIDs coming from draft-vchu-ldap-pwd-policy [1].= Note that AFAIK OpenDJ supports old draft-vchu-ldap-pwd-policy which is v= ery outdated and not supported by LDAP servers without Netscape roots. slapo-ppolicy implements draft-behera-ldap-password-policy [2]. > # Search the root DSE for the password policy (works > # with Netscape Directory Server) > pam_lookup_policy yes >=20 > does not make pam_ldap to interact with password policies against when > configured in openldap. Using pam_ldap is NOT recommended nowadays for a bunch of reasons. Use nss-pam-ldapd, sssd or OpenLDAP's slapo-nssov. AFAIK all of them support draft-behera-ldap-password-policy. But such usage discussion belong on the openldap-technical mailing list a= nd not in the ITS. Ciao, Michael. [1] https://tools.ietf.org/html/draft-vchu-ldap-pwd-policy [2] https://tools.ietf.org/html/draft-behera-ldap-password-policy

1 0

Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
by hyc＠symas.com 29 Jul '15

29 Jul '15

robert.brooks(a)reporo.com wrote: > Full_Name: Robert Brooks > Version: openldap-2.4.41 > OS: Ubuntu 14.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (38.99.38.134) > > > Hi, > > with ppolicy overlay loaded (and functioning) the following root DSE is: > I believe this is why the following pam_ldap config: > > # Search the root DSE for the password policy (works > # with Netscape Directory Server) > pam_lookup_policy yes > > does not make pam_ldap to interact with password policies against when > configured in openldap. No. That controls compatibility with the obsolete/non-standard Netscape-specific password policy attributes. But pam_ldap itself is also obsolete. Pretty sure Ubuntu ships with nslcd and nss-pam-ldapd now. -- -- 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#8208) ppolicy supportedControl not visible in root DSE
by robert.brooks＠reporo.com 29 Jul '15

29 Jul '15

Full_Name: Robert Brooks Version: openldap-2.4.41 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.99.38.134) Hi, with ppolicy overlay loaded (and functioning) the following root DSE is: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: dc=ldap,dc=example,dc=org supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 supportedSASLMechanisms: DIGEST-MD5 supportedSASLMechanisms: NTLM supportedSASLMechanisms: CRAM-MD5 entryDN: subschemaSubentry: cn=Subschema I would expect to see output similar to... http://docs.forgerock.org/en/opendj/2.6.0/dev-guide/index/chap-getting-dire… D0D specifilllly line 12 (and maybe line 40). I believe this is why the following pam_ldap config: # Search the root DSE for the password policy (works # with Netscape Directory Server) pam_lookup_policy yes does not make pam_ldap to interact with password policies against when configured in openldap. Regards, Rob

1 0

Re: (ITS#8206) ldapsearch incorrectly cannonicalizes dns names for GSSAPI
by michael＠stroeder.com 29 Jul '15

29 Jul '15

Calvin Winkowski wrote: >> Did you already try with -N? > > Nope, a bit embarrassed that I didn't find that on my own. Thanks! It > does work with the -N flag. > > I think there is still argument for making that the default and > providing a flag to canonicalize the hostname, but I don't know enough > about GSSAPI's standard to say for certain. I've only used it with > Kerberos. IIRC there was a long-winding sasl-no-canonicalize debate on the mailing lists a while ago. I'm pretty sure nobody wants to repeat that. Ciao, Michael.

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by michael＠stroeder.com 29 Jul '15

29 Jul '15

porjo38(a)yahoo.com.au wrote: > Using password policy overlay, pwdMinLength is not checked when pwdInHistory == > 0. I tried to reproduce this with my local OpenLDAP 2.4.41 installation. In one case I thought to see this but I could not reproduce all the time. Maybe there's another condition for this to happen. Could you please also test with release 2.4.41? And please also post the entry with the password (and relevant pwd* attrs) and the pwdPolicy entry used, both as LDIF (minus sensitive data). Ciao, Michael.

1 0

Re: (ITS#8206) ldapsearch incorrectly cannonicalizes dns names for GSSAPI
by michael＠stroeder.com 29 Jul '15

29 Jul '15

cwinkows(a)vt.edu wrote: > When using ldapsearch GSSAPI mechanism with a server whose reverse DNS name > doesn't match its DNS name, ldapsearch will do the DNS lookups and hand the > reverse DNS entry to GSSAPI. If the reverse DNS entry is not what is used by > kerberos then kerberos will fail. Did you already try with -N? $ ldapsearch -h [..] -N do not use reverse DNS to canonicalize SASL host name [..] Ciao, Michael.

1 0

(ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by porjo38＠yahoo.com.au 29 Jul '15

29 Jul '15

Full_Name: Ian Bishop Version: 2.4.39 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:388:e001:ce00:f2de:f1ff:fea7:d755) Using password policy overlay, pwdMinLength is not checked when pwdInHistory == 0. I tested this by setting pwdMinLength=6 and pwdInHistory=0. I was then able to set a 3 character password. When I changed pwdInHistory > 0 and tried to set a 3 charactepapassword, the attempt was denied. I repeated this several times, and also restarted slapd just in case - same result. Running Openldap 2.4.39 on Centos7, installed from Centos RPM repo.

1 0

(ITS#8206) ldapsearch incorrectly cannonicalizes dns names for GSSAPI
by cwinkows＠vt.edu 28 Jul '15

28 Jul '15

Full_Name: Calvin Winkowski Version: 2.4.41 OS: ArchLinux URL: Submission from: (NULL) (2001:468:c80:a202:3b1d:f567:f43c:7b3a) When using ldapsearch GSSAPI mechanism with a server whose reverse DNS name doesn't match its DNS name, ldapsearch will do the DNS lookups and hand the reverse DNS entry to GSSAPI. If the reverse DNS entry is not what is used by kerberos then kerberos will fail. There are settings in /etc/krb5.conf to disable canonicalizing the hostname provided. I have a server with a record example.ad.example.com whose PTR record is example.example.com, but the realm is ad.example.com and it's entry in the kerberos database is example.ad.example.com, not example.example.com. If I execute the command ``ldapsearch -b "" -s base -Y GSSAPI -D "dn" -H ldap://example.ad.example.com'' GSSAPI will submit a ticket request for example.example.com instead and result in a failure. All other services I've tested with this setup (disabling reverse dns in kerberos) do not give the PTR record, but the user provided hostname. These include mbsync, msmtp, and another ldap utility. I believe that the correct behaviour should be to provide the hostname provided to the utility to GSSAPI. I can provide packet captures illustrating the incorrect lookup if needed.

1 0

(ITS#8205) [PATCH] man pages in contrib
by peter＠adpm.de 26 Jul '15

26 Jul '15

Full_Name: Peter Marschall Version: 2.4.41 OS: Linux URL: Submission from: (NULL) (84.57.119.212) Hi, it always troubled me that the modules in contrib/slapd-modules did either not have a manual page, or - when there was one - did not install it. This week-end Iat down and tried to fix the issue by * amending the Makefiles in contrib to also Rdeal with man page in their install target * writing some man-pages for contrib modules You can find them in ther github branch: https://github.com/marschap/openldap/tree/contrib-manpages It differs from today's master by these commits: * https://github.com/marschap/openldap/commit/25ea4e1e7ab6a6f6a609b70095a0c47… contrib/smbk5pwd: add man page, install it too * https://github.com/marschap/openldap/commit/16395e3b971e3d1734fc1294b5e9ada… contrib/lastbind: install man page * https://github.com/marschap/openldap/commit/2ede55ce9ada228c7382b5bee9e0d29… contrib/passwd/sha2: add man page, install it too * https://github.com/marschap/openldap/commit/d37b3d2f3e297105f603eccbc5221b5… contrib/adremap: install man page * https://github.com/marschap/openldap/commit/e6f3ad1f035f40fd94ac90da14ac8b2… contrib/allop: install man page * https://github.com/marschap/openldap/commit/3b417c99028fb37be3f88afc3da7511… contrib/cloak: install man page * https://github.com/marschap/openldap/commit/9902b56e7830588d761c74a5a5f7b8d… contrib/lastmod: install man page * https://github.com/marschap/openldap/commit/6590fff13b591cdb481daa38c572c2d… contrib/nops: install n n page * https://github.com/marschap/openldap/commit/7f618c17e0f40764fa1590bb9dba5a9… contrib/nssov: install man page * https://github.com/marschap/openldap/commit/b07b66e36ada9c57a85180710b326ed… contrib/passwd: add man page slapd-pw-sha2.5, install it too * https://github.com/marschap/openldap/commit/ca81d5ef6245ece3609a8708376cb91… contrib/passwd/totp: add man page, install it too that change these files contrib/slapd-modules/adremap/Makefile | 14 +- contrib/slapd-modules/allop/Makefile | 14 +- contrib/slapd-modules/cloak/Makefile | 14 +- contrib/slapd-modules/lastbind/Makefile | 14 +- contrib/slapd-modules/lastmod/Makefile | 13 +- contrib/slapd-modules/nops/Makefi | 14 +- contrib/slapd-modules/nssov/Makefile | 15 +- contrib/slapd-modules/passwd/Makefile | 14 +- contrib/slapd-modules/passwd/sha2/Makefile | 14 +- contrib/slapd-modules/passwd/sha2/slapd-pw-sha2.57C7C 118 ++++++++++++++ contrib/slapd-modules/passwd/slapd-pw-radius.5 | 110 +++++++++++++ contrib/slapd-modules/passwd/totp/Makefile | 14 +- contrib/slapd-modules/passwd/totp/slapo-totp.5 | 131 ++++++++++++++++ contrib/slapd-modules/smbk5pwd/Makefile | 14 +- contrib/slapd-modules/smbk5pwd/slapo-smbk5pwd.5 | 179 ++++++++++++++++++++++ 15 files changed, 681 insertions(+), 11 deletions(-) create mode 100644 contrib/slapd-modules/passwd/sha2/slapd-pw-sha2.5 create mode 100644 contrib/slapd-modules/passwd/slapd-pw-radius.5 create mode 100644 contrib/slapd-modules/passwd/totp/slapo-totp.5 create mode 100644 contrib/slapd-modules/smbk5pwd/slapo-smbk5pwd.5 I'd appreciate if you include them into OpenLDAP. The referenced patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Peter Marschall <peter(a)adpm.de>. I have not assigned rights and/or interest in this work to any party. The referenced modifications to OpenLDAP Software are subject to the following notice: Copyright 2015 Peter Marschall Redistribution and use in source and binary forms, with or without modification, are permitted only as authorizedy y the OpenLDAP Public License. Thanks in advance Peter

1 0

(ITS#8204) rfc2782 shuffle implementation doesn't treat equal-weight records equally
by Sergio.Gelato＠astro.su.se 25 Jul '15

25 Jul '15

Full_Name: Sergio Gelato Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.225.123.9) As currently implemented (since ITS#7027, 5de85b922aaa5bfa6eb53db6000adf01ebdb0736) the algorithm to shuffle DNS SRV records of a given priority according to their weights is flawed: if all records have the same weight, the implementation is biased towards the first record and against the last. In the most extreme case of two records of weight 1, the current implementation will never swap them (whereas one would have hoped for a swap 50% of the time). The problem can be cured by changing (r <= 0) to (r < 0). (The wording of the RFC may have contributed to this error; I suspect it was written with real random deviates in mind, not integer ones. In any event, the principle that records of equal weight should have the same probability of being picked trumps the RFC since the latter only says what algorithm SHOULD be used.) I've written and tested a patch for this and found it to solve the above problem. My patch also addresses another (operationally minor, which is why I'm not reporting it separately) issue in the same piece of code: what if at least two, but not all, of the records of a given priority have weight zero? One should be prepared to switch to a Fisher-Yates shuffle if "total" becomes zero during the iteration. (Yet another potential issue is overflow of "total" on platforms where INT_MAX==32767 if the sum of the weights exceeds that value. Consider declaring it uint32_t or u_long.)

1 0

Fix in ITS#8036 is incomplete
by hyc＠openldap.org 24 Jul '15

24 Jul '15

Full_Name: Howard Chu Version: 2.4.41 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.122) Submitted by: hyc The fix in ITS#8036 only corrects the situation for candidate-based searches, not for scope-based searches. In scope-based searches the "fix" treats the scopes array incorrectly and can overwrite the heap. A new fix is coming shortly.

1 0

Re: (ITS#8202) openldap assumes printf has %z
by h.b.furuseth＠usit.uio.no 22 Jul '15

22 Jul '15

On 22. juli 2015 17:54, Howard Chu wrote: > h.b.furuseth(a)usit.uio.no wrote: >> If we require C99 library features like this, then I >> think we should add a configure test for them. Strange >> breakage at runtime is rather worse than a failed build. >> >> (That's not the same as testing for a C99 compiler, since >> one can have a C99 compiler like gcc with a C90 library.) > > The fewer configure tests we need, the better. Happy to replace %zu with %llu > and forget about it. It's not worth a fuss. Right. Looks like it should be %ld and (long) though, we don't use long long either except inside HAVE_LONG_LONG etc and mdb.c -- Hallvard

1 0

Re: (ITS#8202) openldap assumes printf has %z
by hyc＠symas.com 22 Jul '15

22 Jul '15

h.b.furuseth(a)usit.uio.no wrote: > If we require C99 library features like this, then I > think we should add a configure test for them. Strange > breakage at runtime is rather worse than a failed build. > > (That's not the same as testing for a C99 compiler, since > one can have a C99 compiler like gcc with a C90 library.) The fewer configure tests we need, the better. Happy to replace %zu with %llu and forget about it. It's not worth a fuss. -- -- 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#8202) openldap assumes printf has %z
by iand＠ekit-inc.com 22 Jul '15

22 Jul '15

Hi Howard, Yes I'm well aware of the state of Solaris 9 support and we support key components of the OS ourselves. However that doesn't mean that people don't still run it, like we do on some systems yet to be upgraded. (yes we have Sun systems purchased over 15 years ago that are still happily running; the hardware is very reliable; many are well overdue for upgrade though; its a resource/priority thing just look at how many people are running WinXP still) However this issue is a portability of openldap issue, not a OS support/patch thing (the C library in this case is not broken; its doing as the man page says, which doesn't mention %z), and the %z support is only a recent thing in the lifetime of unix (well last ~15 years it started to appear... C99 I think) There will be other legacy OS's that don't support %z too; no idea what ones though. Anyway I've got an (ugly) patch for me to use now and it passes 'make check' on Solaris 9; it was hard to find the cause of the problem though. Ian D On 07/22/15 04:01, Howard Chu wrote: > Howard Chu wrote: >> iand(a)ekit-inc.com wrote: >>> Full_Name: Ian Donaldson >>> Version: 2.4.41 >>> OS: Solaris 9 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (60.241.85.68) >>> >>> >>> Built 2.4.41 on Solaris 9; ran 'make check' which failed to start slapd with >>> the following errors: >> >> Thanks for the report. Not sure that it's worth our taking any action though. >> The last release of Solaris 9 was 10 years ago, and it has been end-of-life'd >> by Oracle. > > For reference: Solaris 9 EOL > http://www.oracle.com/technetwork/server-storage/solaris10/overview/index-1… > > In short it means Solaris 9 is no longer eligible for any Oracle updates including security updates, fixes, patches or any other changes. Solaris 9 went into sustaining support in October 2014. > > Since Oracle is no longer providing any patches for this OS, I don't see much reason for us to either. Fortunately you are free to patch and build OpenLDAP for yourself for as long as you wish. >

1 0

Re: (ITS#8202) openldap assumes printf has %z
by h.b.furuseth＠usit.uio.no 21 Jul '15

21 Jul '15

If we require C99 library features like this, then I think we should add a configure test for them. Strange breakage at runtime is rather worse than a failed build. (That's not the same as testing for a C99 compiler, since one can have a C99 compiler like gcc with a C90 library.)

1 0

Re: (ITS#8202) openldap assumes printf has %z
by hyc＠symas.com 21 Jul '15

21 Jul '15

Howard Chu wrote: > iand(a)ekit-inc.com wrote: >> Full_Name: Ian Donaldson >> Version: 2.4.41 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (60.241.85.68) >> >> >> Built 2.4.41 on Solaris 9; ran 'make check' which failed to start slapd with >> the following errors: > > Thanks for the report. Not sure that it's worth our taking any action though. > The last release of Solaris 9 was 10 years ago, and it has been end-of-life'd > by Oracle. For reference: Solaris 9 EOL http://www.oracle.com/technetwork/server-storage/solaris10/overview/index-1… In short it means Solaris 9 is no longer eligible for any Oracle updates including security updates, fixes, patches or any other changes. Solaris 9 went into sustaining support in October 2014. Since Oracle is no longer providing any patches for this OS, I don't see much reason for us to either. Fortunately you are free to patch and build OpenLDAP for yourself for as long as you wish. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs