openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#8949) slapd crashes when adding first olcPlugin value
by ryan＠openldap.org 01 Jan '19

01 Jan '19

Full_Name: Ryan Tandy Version: 2.4, master OS: Debian URL: Submission from: (NULL) (70.66.128.207) Submitted by: ryan Initial configuration, no existing value for olcPlugin: ldapmodify -H ldap://:9000 -x -D cn=config -w secret << eof dn: olcDatabase={1}mdb,cn=config add: olcPlugin olcPlugin: preoperation ./libtestpreop-plugin.so testpreop_init eof Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff6020700 (LWP 17326)] 0x00005555556ee351 in slapi_int_free_object_extensions (objecttype=1, object=0x7fffec000cb0) at slapi_ext.c:298 298 if ( eblock->extensions != NULL ) { (gdb) bt #0 0x00005555556ee351 in slapi_int_free_object_extensions (objecttype=1, object=0x7fffec000cb0) at slapi_ext.c:298 #1 0x00005555555c14f3 in slap_op_free (op=0x7fffec000cb0, ctx=0x7ffff601fb90) at operation.c:113 #2 0x00005555555a62c6 in connection_operation (ctx=0x7ffff601fb90, arg_v=0x7fffec000cb0) at connection.c:1246 #3 0x00005555555a6577 in connection_read_thread (ctx=0x7ffff601fb90, argv=0xb) at connection.c:1326 #4 0x00005555556a2dff in ldap_int_thread_pool_wrapper (xpool=0x55555580cc40) at tpool.c:1048 #5 0x00007ffff7f7ffa3 in start_thread (arg=<optimized out>) at pthread_create.c:486 #6 0x00007ffff7eb089f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 It looks like we went through slap_op_alloc() with slapi_plugins_used = 0, so slapi_int_create_object_extensions() was never called, but in slap_op_free() we have added a plugin and have called slapi_int_free_object_extensions(). Can probably be fixed just by short-circuiting when eblock == NULL?

1 0

(ITS#9535) -ldb incorrectly added to SLAPD_LIBS with modular build
by quanah＠openldap.org 31 Dec '18

31 Dec '18

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) configure.in has the following section handling the BDB library: if test $ol_enable_bdb/$ol_enable_hdb != no/no; then OL_BERKELEY_DB if test $ol_cv_berkeley_db = no ; then AC_MSG_ERROR(BDB/HDB: BerkeleyDB not available) fi AC_DEFINE(HAVE_BERKELEY_DB,1, [define this if Berkeley DB is available]) dnl $ol_cv_lib_db should be yes or -ldb dnl (it could be no, but that would be an error if test $ol_cv_lib_db != yes ; then BDB_LIBS="$BDB_LIBS $ol_cv_lib_db" fi SLAPD_LIBS="$SLAPD_LIBS \$(BDB_LIBS)" ol_link_bdb=yes fi This has the effect of always attempting to link the slapd binary with the BDB library. This block should instead be: if test $ol_enable_bdb/$ol_enable_hdb != no/no; then OL_BERKELEY_DB if test $ol_cv_berkeley_db = no ; then AC_MSG_ERROR(BDB/HDB: BerkeleyDB not available) fi AC_DEFINE(HAVE_BERKELEY_DB,1, [define this if Berkeley DB is available]) dnl $ol_cv_lib_db should be yes or -ldb dnl (it could be no, but that would be an error if test $ol_cv_lib_db != yes ; then BDB_LIBS="$BDB_LIBS $ol_cv_lib_db" fi dnl link BDB library to slapd with static backend if test $ol_enable_bdb/$ol_enable_hdb != mod/mod; then SLAPD_LIBS="$SLAPD_LIBS \$(BDB_LIBS)" fi ol_link_bdb=yes fi

1 0

(ITS#9534) openldap bug
by 349020753＠qq.com 25 Dec '18

25 Dec '18

Full_Name: perfy Version: 2.4.44 OS: centos 7 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (1.202.220.123) (1)I have enabled the dynlist moudle as follows: [root@test01 cn=schema]# pwd /etc/openldap/slapd.d/cn=config/cn=schema [root@test01 cn=schema]# ll total 84 -rw-r-----. 1 ldap ldap 1283 Dec 18 17:50 cn={0}corba.ldif -rw-r-----. 1 ldap ldap 3625 Dec 18 17:50 cn={10}ppolicy.ldif -rw-r-----. 1 ldap ldap 1523 Dec 18 17:50 cn={11}collective.ldif -rw------- 1 ldap ldap 2727 Dec 18 17:37 cn={12}sudo.ldif -rw------- 1 ldap ldap 1013 Dec 19 01:16 cn={13}ldapns.ldif -rw-r-----. 1 ldap ldap 15546 Dec 18 17:50 cn={1}core.ldif -rw-r-----. 1 ldap ldap 11363 Dec 18 17:50 cn={2}cosine.ldif -rw-r-----. 1 ldap ldap 4489 Dec 18 17:50 cn={3}duaconf.ldif -rw-r-----. 1 ldap ldap 1693 Dec 18 17:50 cn={4}dyngroup.ldif -rw-r-----. 1 ldap ldap 2857 Dec 18 17:50 cn={5}inetorgperson.ldif -rw-r-----. 1 ldap ldap 2589 Dec 18 17:50 cn={6}java.ldif -rw-r-----. 1 ldap ldap 1519 Dec 18 17:50 cn={7}misc.ldif -rw-r-----. 1 ldap ldap 6495 Dec 18 17:50 cn={8}nis.ldif -rw-r-----. 1 ldap ldap 1323 Dec 18 17:50 cn={9}openldap.ldif [root@test01 cn=config]# cat cn=module{0}.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 e9c5e751 dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}dynlist.la olcModuleLoad: {1}ppolicy.la structuralObjectClass: olcModuleList entryUUID: 78bc6ce2-972e-1038-9a09-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163402Z entryCSN: 20181220075834.004947Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20181220075834Z [root@test01 cn=config]# cat olcDatabase\=\{2\}bdb/olcOverlay\=\{0\}dynlist.ldif dn: olcOverlay={0}dynlist objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {0}dynlist olcDlAttrSet: {0}inetOrgPerson labeledURI olcDlAttrSet: {1}groupOfURLs memberURL member structuralObjectClass: olcDynamicList entryUUID: 0ff96984-972f-1038-9a0b-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163815Z entryCSN: 20181221095210.059382Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth [root@test01 cn=schema]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "ou=dbhost" dn: ou=dbhost,ou=servers,dc=kb,dc=com objectClass: organizationalUnit objectClass: hostObject ou: dbhost host: test04 [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "uid=zhangsan" dn: uid=zhangsan,ou=People,dc=kb,dc=com objectClass: posixAccount objectClass: inetOrgPerson objectClass: shadowAccount objectClass: hostObject cn: zhangsan sn: zhangsan uid: zhangsan uidNumber: 10007 homeDirectory: /home/zhangsan loginShell: /bin/bash gecos: DBA Manager shadowLastChange: 17889 gidNumber: 10011 labeledURI: ldap:///ou=dbhost,ou=servers,dc=kb,dc=com?host userPassword:: e01ENX00UXJjT1VtNldhdStWdUJYOGcrSVBnPT0= host: test04 (2)When I search the hostname "test04" by the filter "(&(uid=zhangsan)(host=test04))", no any result is return. The corrent result should return the DN "dn: uid=zhangsan,ou=People,dc=kb,dc=com". But the result is empty. Is it a bug ? [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "(&(uid=zhangsan)(host=test04))"

1 0

(ITS#9533) openldap bug
by 349020753＠qq.com 25 Dec '18

25 Dec '18

Full_Name: perfy Version: 2.4.44 OS: centos 7 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (1.202.220.123) (1)I have enabled the dynlist moudle as follows: [root@test01 cn=schema]# pwd /etc/openldap/slapd.d/cn=config/cn=schema [root@test01 cn=schema]# ll total 84 -rw-r-----. 1 ldap ldap 1283 Dec 18 17:50 cn={0}corba.ldif -rw-r-----. 1 ldap ldap 3625 Dec 18 17:50 cn={10}ppolicy.ldif -rw-r-----. 1 ldap ldap 1523 Dec 18 17:50 cn={11}collective.ldif -rw------- 1 ldap ldap 2727 Dec 18 17:37 cn={12}sudo.ldif -rw------- 1 ldap ldap 1013 Dec 19 01:16 cn={13}ldapns.ldif -rw-r-----. 1 ldap ldap 15546 Dec 18 17:50 cn={1}core.ldif -rw-r-----. 1 ldap ldap 11363 Dec 18 17:50 cn={2}cosine.ldif -rw-r-----. 1 ldap ldap 4489 Dec 18 17:50 cn={3}duaconf.ldif -rw-r-----. 1 ldap ldap 1693 Dec 18 17:50 cn={4}dyngroup.ldif -rw-r-----. 1 ldap ldap 2857 Dec 18 17:50 cn={5}inetorgperson.ldif -rw-r-----. 1 ldap ldap 2589 Dec 18 17:50 cn={6}java.ldif -rw-r-----. 1 ldap ldap 1519 Dec 18 17:50 cn={7}misc.ldif -rw-r-----. 1 ldap ldap 6495 Dec 18 17:50 cn={8}nis.ldif -rw-r-----. 1 ldap ldap 1323 Dec 18 17:50 cn={9}openldap.ldif [root@test01 cn=config]# cat cn=module{0}.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 e9c5e751 dn: cn=module{0} objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}dynlist.la olcModuleLoad: {1}ppolicy.la structuralObjectClass: olcModuleList entryUUID: 78bc6ce2-972e-1038-9a09-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163402Z entryCSN: 20181220075834.004947Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20181220075834Z [root@test01 cn=config]# cat olcDatabase\=\{2\}bdb/olcOverlay\=\{0\}dynlist.ldif dn: olcOverlay={0}dynlist objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {0}dynlist olcDlAttrSet: {0}inetOrgPerson labeledURI olcDlAttrSet: {1}groupOfURLs memberURL member structuralObjectClass: olcDynamicList entryUUID: 0ff96984-972f-1038-9a0b-0b17f1a1373f creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20181218163815Z entryCSN: 20181221095210.059382Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth [root@test01 cn=schema]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "ou=dbhost" dn: ou=dbhost,ou=servers,dc=kb,dc=com objectClass: organizationalUnit objectClass: hostObject ou: dbhost host: test04 [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "uid=zhangsan" dn: uid=zhangsan,ou=People,dc=kb,dc=com objectClass: posixAccount objectClass: inetOrgPerson objectClass: shadowAccount objectClass: hostObject cn: zhangsan sn: zhangsan uid: zhangsan uidNumber: 10007 homeDirectory: /home/zhangsan loginShell: /bin/bash gecos: DBA Manager shadowLastChange: 17889 gidNumber: 10011 labeledURI: ldap:///ou=dbhost,ou=servers,dc=kb,dc=com?host userPassword:: e01ENX00UXJjT1VtNldhdStWdUJYOGcrSVBnPT0= host: test04 (2)When I search the hostname "test04" by the filter "(&(uid=zhangsan)(host=test04))", no any result is return. The corrent result should return the DN "dn: uid=zhangsan,ou=People,dc=kb,dc=com". But no result is empty. Is it a bug ? [root@test01 cn=config]# ldapsearch -LLL -x -D "cn=Manager,dc=kb,dc=com" -b "dc=kb,dc=com" -w1234 "(&(uid=zhangsan)(host=test04))"

1 0

(ITS#9532) Ambiguos documentation for default LogLevel
by dpa-openldap＠aegee.org 23 Dec '18

23 Dec '18

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4.47 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (46.5.16.188) If LogLevel is not specified, does it default to 0 or to 256 (stats)? The documentation says default is stats in: man/man5/slapd.conf.5:691:The loglevel defaults to \fBstats\fP. guide/admin/tuning.sdf:121:The default of {{loglevel stats}} (256) is really the best bet. There's a corollary to guide/admin/tuning.sdf-141-The default syslog level is stats (256) which logs the basic parameters of each And the default for loglevel 0 is defined at: man/man5/slapd-config.5:630:In fact, if no olcLogLevel (or a 0 level) is defined, no logging occurs, man/man5/slapd-config.5-631-so at least the man/man5/slapd-config.5-632-.B none man/man5/slapd-config.5-633-level is required to have high priority messages logged. Here mixed feelings: guide/admin/slapdconfig.sdf-193-\Default: guide/admin/slapdconfig.sdf-194- guide/admin/slapdconfig.sdf:195:E: loglevel stats guide/admin/slapdconfig.sdf-196- guide/admin/slapdconfig.sdf:197:Basic stats logging is configured by default. However, if no loglevel is guide/admin/slapdconfig.sdf-198-defined, no logging occurs (equivalent to a 0 level). guide/admin/slapdconfig.sdf-199- guide/admin/slapdconf2.sdf-237- guide/admin/slapdconf2.sdf-238-\Default: guide/admin/slapdconf2.sdf-239- guide/admin/slapdconf2.sdf:240:E: olcLogLevel stats guide/admin/slapdconf2.sdf-241- guide/admin/slapdconf2.sdf:242:Basic stats logging is configured by default. However, if no olcLogLevel is guide/admin/slapdconf2.sdf-243-defined, no logging occurs (equivalent to a 0 level). guide/admin/slapdconf2.sdf-244- I suggest describing all default values at a single place.

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 19 Dec '18

19 Dec '18

Thorsten Glaser wrote: > Howard Chu dixit: > >> Thanks to the wonderful geniuses at Microsoft, not all the world >> uses LP64. IL32 is a thing. And this code works on those platforms. > > These changes do not break LLP64 (this is the correct name > for the 64-bit Windows model). Yes, they do, but you're clearly too stupid to understand that, despite having had it explained to you multiple times. Your patch tries to store the value of a long long into a buffer only large enough for a long. That is fucking stupid. Bye. -- -- 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#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠mirbsd.de 18 Dec '18

18 Dec '18

Howard Chu dixit: >Thanks to the wonderful geniuses at Microsoft, not all the world >uses LP64. IL32 is a thing. And this code works on those platforms. These changes do not break LLP64 (this is the correct name for the 64-bit Windows model). >If you're going to submit a patch, submit a correct one. It's that The buffer size is a separate issue from this. Feel free to fix it, now that you found it. The patch I submit fixed your software on systems where time_t doesn=E2=80=99t fit into a long, all of them, and that *will* include 64-bit Windows at least in 2038, except some architectures need these fixes right now. They don=E2=80=99t break anything else before 2038, and afterwards, nothing new is broken worsely either. >simple. If you refuse to do that, then go away. You know what, I=E2=80=99ll just do that and leave you to fix your software on your own, clearly you are oh so utterly competent in doing that. //mirabilos --=20 =E2=80=9CIt is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.=E2=80=9D =09-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 18 Dec '18

18 Dec '18

Thorsten Glaser wrote: > Howard Chu dixit: >=20 >> This patch of yours *introduces a bug*. If you wanted to actually *fix= * >> something you should have made sure the malloc'd buffer - which only h= appens >> 2 lines above the lines you change - was large enough to store a long = long. >=20 > That=E2=80=99s not a new bug, then. > That=E2=80=99s a completely separate Y2038 issue of *yours* that > will happen on all platforms, and has nothing to do with > long vs. long long, since a long on an LP64 platform *is* > already as wide as a long long. Thanks to the wonderful geniuses at Microsoft, not all the world uses LP64. IL32 is a thing. And this code works on those platforms. Far more machines than have ever or ever will run X32. If you want patches for your obscure system adopted, you have to make sure not to break anything else. > In addition to that, use of snprintf will prevent this > from being worse than a mere truncation. If you're going to submit a patch, submit a correct one. It's that simple= . If you refuse to do that, then go away. --=20 -- 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#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠mirbsd.de 18 Dec '18

18 Dec '18

Howard Chu dixit: >This patch of yours *introduces a bug*. If you wanted to actually *fix* >something you should have made sure the malloc'd buffer - which only happe= ns >2 lines above the lines you change - was large enough to store a long long= =2E That=E2=80=99s not a new bug, then. That=E2=80=99s a completely separate Y2038 issue of *yours* that will happen on all platforms, and has nothing to do with long vs. long long, since a long on an LP64 platform *is* already as wide as a long long. In addition to that, use of snprintf will prevent this from being worse than a mere truncation. bye, //mirabilos --=20 Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend.=09=09-- Andreas Bogk =C3=BCber boehm-gc in d.a.s.r

1 0

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by hyc＠symas.com 18 Dec '18

18 Dec '18

Thorsten Glaser wrote: > I know my way *very* well around the time_t issue because > I=E2=80=99ve been having them on MirBSD/i386 years before x32 even > existed, and am experienced in how to fix them. >From here it only looks like you're experienced in how to break things. This patch of yours *introduces a bug*. If you wanted to actually *fix* something you should have made sure the malloc'd buffer - which only happ= ens 2 lines above the lines you change - was large enough to store a long lon= g. That's just plain sloppy. It's as careless as submitting a patch to fix a no-op, and just wasting my time. +--- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c ++++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c +@@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time()); ++ "%lld", (long long)slap_get_time()); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdLastSet; +@@ -627,7 +627,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time() + pi->smb_must_change); ++ "%lld", (long long)slap_get_time() + (long long)pi->s= mb_must_change); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdMustChange; +@@ -650,7 +650,7 @@ static int smbk5pwd_exop_passwd( + keys[0].bv_val =3D ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) ); + keys[0].bv_len =3D snprintf(keys[0].bv_val, + LDAP_PVT_INTTYPE_CHARS(long), +- "%ld", slap_get_time() + pi->smb_can_change); ++ "%lld", (long long)slap_get_time() + (long long)pi->s= mb_can_change); + BER_BVZERO( &keys[1] ); + + ml->sml_desc =3D ad_sambaPwdCanChange; --=20 -- 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