openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Start a nNew thread

ITS#9047 published: SECURITY: Coverity report on LMDB
by openldap-its＠OpenLDAP.org 08 Jul '19

08 Jul '19

Private ITS#9047 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=9047

1 0

Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com 08 Jul '19

08 Jul '19

--On Thursday, June 27, 2019 8:56 PM +0000 quanah(a)symas.com wrote: > --On Thursday, June 27, 2019 8:35 PM +0000 hyc(a)symas.com wrote: > >> No, because order is irrelevant for these. > > Cool, thanks! I'll continue on with deeper testing then. :) Given the current implementation of OpenLDAP, this feature is impossible to use w/o recompiling OpenLDAP when a change to the IDL size is made. This is because LDAP_PVT_THREAD_STACK_SIZE must be adjusted as well and that requires a recompile. The default size for LDAP_PVT_THREAD_STACK_SIZE is: ( 1 * 1024 * 1024 * sizeof(void *) ) which works for an IDL size of 16 (2^16) which is 65536. If you change the IDL size, say to 22, then the new IDL size is: 4,194,304. We then use this difference to find the offset we need to adjust LDAP_PVT_THREAD_STACK_SIZE by: 4194304/65536 = 64 So it needs to be 64 time larger: ( 64 * 1024 * 1024 * sizeof(void *) ) Generally, this feature is simply unusuable (currently) as a tunable given the requirement for recompiling OpenLDAP to use it. --QUanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9045) Crashes in cn=config (test050)
by ondra＠openldap.org 02 Jul '19

02 Jul '19

On Fri, Jun 28, 2019 at 09:49:51AM +0000, ondra(a)openldap.org wrote: > Every so often (roughly once in a thousand runs or so it seems), a server will > crash in test050 on master. This test replicates cn=config which is not > officially supported yet. > > Some output from a gdb session from the core is uploaded here: > ftp://ftp.openldap.org/incoming/test050-crash-master-20190628.txt > > It's not clear to me how attrs_dup has reached the attribute at 0x170b6a8 unless > there was another thread messing with the same structure. str2entry2 is running > in another thread, but I wouldn't think it runs on the same entry? Stuff is > optimised out in this one. Another crash, this time with better logs and an unoptimized binary: ftp://ftp.openldap.org/incoming/test050-crash-20190702.txz Again, attribute is being accessed that seems to have been cleaned and released and another thread is running str2entry2 (on cn=config as well, just with a different pointer), might still be a red herring. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9046) Regex Constraint Overlay Error
by mrojo＠gmv.com 01 Jul '19

01 Jul '19

Full_Name: Mar.a Rojo Gonz.lez Version: 2.4.44 OS: CentOS Linux release 7.6.1810 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.0.110.2) Hello, We installed a fresh OpenLDAP server and created the following test backend: # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 a008278f dn: olcDatabase={3}hdb objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {3}hdb olcDbDirectory: /var/lib/ldap2 olcSuffix: dc=example,dc=org olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonym ous auth by dn="cn=admin,dc=example,dc=org" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=org" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=example,dc=org olcRootPW:: e1NTSEF9RnZwTERwWkFQRlhId012TnhBWXpkemY3b0JUN2tNR3M= olcDbCheckpoint: 512 30 olcDbIndex: objectClass eq structuralObjectClass: olcHdbConfig entryUUID: 238efe88-303a-1039-97b5-d1f261d139b7 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20190701105301Z entryCSN: 20190701105301.031755Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20190701105301Z Then we added the following constraint using ldapadd: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap/ olcModuleLoad: constraint.la dn: olcOverlay=constraint,olcDatabase={3}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcConstraintConfig olcOverlay: constraint olcConstraintAttribute: userPassword regex ^[^{].* Finally, we tested some combinations of passwords and constraints (replacing the previous olcConstraintAttribute) and these are the results: # Operation Password Constraint Result 1 ldapmodify hola ^[^{].* err=0 2 ldapmodify {hola ^[^{].* err=19 3 ldappasswd hola ^[^{].* err=19 4 ldappasswd {hola ^[^{].* err=19 5 ldapmodify hola ^[^H].* err=0 6 ldapmodify Hola ^[^H].* err=19 7 ldappasswd hola ^[^H].* err=0 8 ldappasswd Hola ^[^H].* err=0 where the ldapmodify was executed as follows: ldapmodify -x -D "cn=person1,ou=people,dc=example,dc=org" -W Enter LDAP Password: dn: cn=person1,ou=people,dc=example,dc=org changetype: modify replace: userPassword userPassword: hola modifying entry "cn=person1,ou=people,dc=example,dc=org" and ldappasswd was run as such: ldappasswd -x -D "cn=person1,ou=people,dc=example,dc=org" -w pass -a pass -s hola Result: Constraint violation (19) The unexpected results were: # Operation Password Constraint Result 3 ldappasswd hola ^[^{].* err=19 8 ldappasswd Hola ^[^H].* err=0 Here is some sample output from the slapd log files: Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 fd=26 ACCEPT from IP=[::1]:33328 (IP=[::]:389) Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=0 BIND dn="cn=person1,ou=people,dc=example,dc=org" method=128 Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=0 BIND dn="cn=person1,ou=people,dc=example,dc=org" mech=SIMPLE ssf=0 Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=0 RESULT tag=97 err=0 text= Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=1 PASSMOD old new Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=1 RESULT oid= err=19 text=(#001 Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=2 UNBIND Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 fd=26 closed Note the strange text on the RESULT. We consistently found the same error text when we executed executing test #3. Do you know what may be causing this behaviour? Thank you in advance.

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 28 Jun '19

28 Jun '19

Quanah, I can think of three reasons why the patch is causing problems: 1. The patch is three years old and was not validated against the current OpenLDAP version, to which it has been applied. Without additional testing, I am not even sure if the issue that the patch fixes still exists. 2. The patch was not tested in the proxy configuration. 3. The patch changes the way tls_reqcert parameter is handled. It is therefore possible that a setup with an incorrect TLS certificate would stop working. However, that is a general remark and the cause of Abdelkader Chelouah's problems may be entirely different. Unfortunately, I do not feel that I would be able to help with any further work on this patch. Due to the passage of time since this bug was reported, I would need to redo all the work from scratch (my test environment is long gone, and the limited understanding of OpenLDAP internals that I once had, has since faded from my memory). I do not believe that I can afford such an effort, particularly when I worry that the result could be shelved for years again. I would be grateful if others, who are more knowledgeable with OpenLDAP internals, look into this issue. Thank you very much Maciej Puzio

1 0

(ITS#9045) Crashes in cn=config (test050)
by ondra＠openldap.org 28 Jun '19

28 Jun '19

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.10.24.68) Every so often (roughly once in a thousand runs or so it seems), a server will crash in test050 on master. This test replicates cn=config which is not officially supported yet. Some output from a gdb session from the core is uploaded here: ftp://ftp.openldap.org/incoming/test050-crash-master-20190628.txt It's not clear to me how attrs_dup has reached the attribute at 0x170b6a8 unless there was another thread messing with the same structure. str2entry2 is running in another thread, but I wouldn't think it runs on the same entry? Stuff is optimised out in this one.

1 0

(ITS#9044) fanruan
by leo.li＠fanruan.com 27 Jun '19

27 Jun '19

Full_Name: leo.li Version: 2.4.44 OS: CentOS7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (114.223.227.133) I want to deploy Openldap server with the backend of mysql. By following https://gist.github.com/mahirrudin/9b7754e54f1e8e532049484864beba42#file-ub… , Openldap is started but I can't add new records. Log shows, 5d15b75a <<< dnPrettyNormal: <dc=fanruan,dc=com>, <dc=fanruan,dc=com> 5d15b75a ==>backsql_add("dc=fanruan,dc=com") 5d15b75a oc_check_required entry (dc=fanruan,dc=com), objectClass "dcObject" 5d15b75a oc_check_required entry (dc=fanruan,dc=com), objectClass "organization" 5d15b75a oc_check_allowed type "o" 5d15b75a oc_check_allowed type "objectClass" 5d15b75a oc_check_allowed type "structuralObjectClass" 5d15b75a oc_check_allowed type "dc" 5d15b75a backsql_add("dc=fanruan,dc=com"): create procedure is not defined for structuralObjectClass "organization" - aborting 5d15b75a send_ldap_result: conn=1012 op=1 p=3 5d15b75a send_ldap_result: err=53 matched="" text="operation not permitted within namingContext" 5d15b75a send_ldap_response: msgid=2 tag=105 err=53 ber_flush2: 58 bytes to sd 10 5d15b75a <==backsql_add("dc=fanruan,dc=com"): 53 "operation not permitted within namingContext" 5d15b75a connection_get(10) 5d15b75a connection_get(10): got connid=1012 5d15b75a connection_read(10): checking for input on id=1012 ber_get_next ber_get_next: tag 0x30 len 5 contents: 5d15b75a op tag 0x42, time 1561704282 I know I need to configure mysql table but how to do it? Any guide for it ?

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by quanah＠symas.com 27 Jun '19

27 Jun '19

--On Sunday, April 07, 2019 10:15 AM +0000 henrik.bohnenkamp(a)ionos.com wrote: > On Thu, Apr 04, 2019 at 05:32:16PM +0100, Howard Chu wrote: > Hi Howard, > > thanks for your comments. There is now a new version of patches available > in my github repository. Apart from addressing your comments, I have > rebased the patches against the current master branch (quite a lot > activity in the last two months, I have noticed). In particular, the new > function mdb_get_aliases now also uses the global size variables for IDL > dimensions, rather than the previous CPP constants. Had a customer who was hitting this issue try out these patches -- It greatly decreases the search time (from unknown/infinite to 1 minute). Unfortunately slapd then segv's. Working on getting a test database to reproduce the issue with for a good backtrace. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by quanah＠symas.com 27 Jun '19

27 Jun '19

Hello, Unfortunately this patch introduces a regression and breaks existing configurations where the protocol in use is ldaps:///. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Regression after ITS#8427 fix with back-ldap
by quanah＠symas.com 27 Jun '19

27 Jun '19

--On Thursday, June 27, 2019 11:51 PM +0200 Abdelkader Chelouah <a.chelouah(a)gmail.com> wrote: > > I tried with with > > > olcDbStartTLS: ldaps > > > with no success. > > > Logs on the proxy > > > 2019-06-27T20:46:07.602925+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > fd=11 ACCEPT from IP=[::1]:46462 (IP=[::1]:10020) > 2019-06-27T20:46:07.603476+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 BIND dn="uid=alice,ou=people,dc=local" method=128 > 2019-06-27T20:46:07.609212+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 ldap_back_retry: retrying URI="ldaps://arrakis.local:10011" DN="" > 2019-06-27T20:46:07.613435+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 RESULT tag=97 err=52 text=Proxy operation retry failed > 2019-06-27T20:46:07.613968+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=1 UNBIND > 2019-06-27T20:46:07.614264+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > fd=11 closed > > Logs on the backend ldap server > > > 2019-06-27T20:46:07.609971+00:00 arrakis slapd-2.4-aa[14682]: conn=1011 > fd=12 ACCEPT from IP=172.18.0.2:47156 (IP=172.18.0.2:10011) > 2019-06-27T20:46:07.613718+00:00 arrakis slapd-2.4-aa[14682]: conn=1011 > fd=12 closed (TLS negotiation failure) Thanks! Please include the openldap-its list in your replies so that they properly get associated with the relevant ITS. I'll raise this up as a priority for the 2.4.48 release. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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