openldap-bugs December 2018

openldap-bugs@openldap.org

10 participants
25 discussions

(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

Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems
by tg＠debian.org 18 Dec '18

18 Dec '18

Howard Chu dixit: >You might have correctly identified a Y2038 issue. You certainly have not >written a correct fix for it. Please drop this condescending attitude. I may or may not have discovered a Y2038 issue, but I do know for sure I=E2=80=99ve correctly fixed a problem on all architectures in which a time_t does not fit into a long. Consider this: #ifdef TEST1 typedef long foo_t; #else typedef long long foo_t; #endif foo_t bla =3D 1L; printf("%ld, %ld\n", bla, 2L); This is _supposed_ to display =E2=80=9C1, 2=E2=80=9D but will display =E2= =80=9C1, 0=E2=80=9D on little endian platforms (big endian being worse off). 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. bye, //mirabilos --=20 16:47=E2=8E=9C=C2=ABmika:#grml=C2=BB .oO(mira ist einfach gut....) 23:= 22=E2=8E=9C=C2=ABmikap:#grml=C2=BB mirabilos: und dein bootloader ist geil :) 23:29=E2=8E=9C=C2=ABmikap:#gr= ml=C2=BB und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren=09-- Michael Prokop =C3=BCber MirOS b= sd4grml

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2018