openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#7769) [PATCH] Fix typo in slapd-meta manpage.
by jsynacek＠redhat.com 17 Dec '13

17 Dec '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 19 URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20131217-0001-Fix-typo-i… Submission from: (NULL) (209.132.186.34) Fix for a typo in slapd-meta.5

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by ck＠cksoft.de 16 Dec '13

16 Dec '13

Hi, On Mon, 16 Dec 2013, coudot(a)linagora.com wrote: > Full_Name: Cl?ment OUDOT > Version: 2.4.38 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > I have a simple setup with a master (overlay syncprov + overlay ppolicy) and a > slave (syncrepl client, overlay ppolicy). > > 1. I lock my account in the slave > 2. I change the description attribute of my account a first time in the master > 3. My account is still locked in the slave > 4. I change the description attribute of my account a second time in the master > 5. My account is no more locked in the slave: the password policy operational > attributes pwdFailureTime and pwdAccountUnlockTime were erased by the one of the > master > > Seems like a control is done the first time that syncrepl update the entry (the > first time, pwdAccountLockTime and pwdFailureTime are not erased), but the > second time the control is not done. I have had a very similar setup for some time now and have never observed this kind of behaviour from the ppolicy overlay. I am quite confident it should work correctly in the situation you describe. There might be a valid reason for pwdAccountLockedtime and pwdFailureTime attributes disappearing like perhaps expiry of pwdLockoutDuration. Please see the account_locked() function in servers/slapd/overlay/ppolicy.c for this. It is of course also quite possible that you have hit a special corner case that nobody else has yet found. The best thing you could do would be to setup a small self contained test case to illustrate the problem. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7764) RFE: library lber method which returns the ber size even if the ber is overflown
by nhosoi＠gmail.com 16 Dec '13

16 Dec '13

--001a11c1a2f087afb804edaadb8d Content-Type: text/plain; charset=ISO-8859-1 Thank you, Howard! You are right. We are not getting LBER_OVERFLOW, but having the return code LBER_DEFAULT and "errno == ERANGE". Also, indeed there is no particular size limits in openldap lber library unless setting the max incoming ber size with this API: ber_sockbuf_ctrl(sockbuf, LBER_SB_OPT_SET_MAX_INCOMING, &maxsize); We'd like to avoid receiving, e.g., 100MB ber's, but we'd like to also have a method to log the rejected incoming ber size just in case the administrator may want to allow to receive it. Best regards, --Noriko Hosoi On Sun, Dec 15, 2013 at 3:58 AM, Howard Chu <hyc(a)symas.com> wrote: > nhosoi(a)gmail.com wrote: > >> Full_Name: Noriko Hosoi >> Version: 2.4.35-4 >> OS: Fedora 18 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.132.181.86) >> >> >> We use the OpenLdap library in our software. LDAP clients could send too >> large >> ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. We'd >> like to >> learn how large the ber size we should prepare from the error. When we >> look >> into the BerElement ber using gdb, ber->ber_len stores the value. But the >> value >> is not returned to the caller when the API fails, e.g., by the overflow. >> Could >> it be possible to have a way to retrieve the ber size under any condition? >> > > That doesn't sound like OpenLDAP, we have no LBER_OVERFLOW error code. Nor > do we have any particular size limits on a BerElement, other than fitting > into a long. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a11c1a2f087afb804edaadb8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div>Thank you, Howard!=A0 <br><br>You are right= .=A0 We are not getting LBER_OVERFLOW, but having the return code LBER_DEFA= ULT and "errno =3D=3D ERANGE".=A0 Also, indeed there is no partic= ular size limits in openldap lber library unless setting the max incoming b= er size with this API:<br> =A0=A0=A0 ber_sockbuf_ctrl(sockbuf, LBER_SB_OPT_SET_MAX_INCOMING, &maxs= ize);<br><br></div>We'd like to avoid receiving, e.g., 100MB ber's,= but we'd like to also have a method to log the rejected incoming ber s= ize just in case the administrator may want to allow to receive it.<br> <br></div>Best regards,<br></div>--Noriko Hosoi<br></div><div class=3D"gmai= l_extra"><br><br><div class=3D"gmail_quote">On Sun, Dec 15, 2013 at 3:58 AM= , Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target= =3D"_blank">hyc(a)symas.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:nhosoi@gmail.com" target= =3D"_blank">nhosoi(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Noriko Hosoi<br> Version: 2.4.35-4<br> OS: Fedora 18<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/<u></u>incoming/</a><br> Submission from: (NULL) (209.132.181.86)<br> <br> <br> We use the OpenLdap library in our software. =A0LDAP clients could send too= large<br> ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. =A0We'd= like to<br> learn how large the ber size we should prepare from the error. =A0When we l= ook<br> into the BerElement ber using gdb, ber->ber_len stores the value. But th= e value<br> is not returned to the caller when the API fails, e.g., by the overflow. = =A0Could<br> it be possible to have a way to retrieve the ber size under any condition?<= br> </blockquote> <br> That doesn't sound like OpenLDAP, we have no LBER_OVERFLOW error code. = Nor do we have any particular size limits on a BerElement, other than fitti= ng into a long.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =A0 -- Howard Chu<br> =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a><br> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a><br> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br></div> --001a11c1a2f087afb804edaadb8d--

1 0

(ITS#7768) Use of olcDbUri in LDAP/Chain configuration for ppolicy_forward_updates
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) I set up a slave configuration with ppolicy_forward_updates feature. In my data backend config, I have: olcUpdateRef: ldap://localhost:389 And I created the chain overlay and a sub ldap backend like this: dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: top objectClass: olcConfig objectClass: olcChainConfig objectClass: olcOverlayConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbIDAssertBind: bindmethod="simple" binddn="cn=admin,dc=example,dc=com" credentials="secret" mode="none" This configuration do not work: the BIND on the master server is done anonymously, despite the olcDbIDAssertBind value. To work, I need to add: olcDbUri: ldap://localhost:389 Seems the problem exist in OpenLDAP unit test 32, see tests/data/slapd-chain1.conf : # uses the chain overlay as global; # no chain-URI is configured, so the URI is parsed out of the referral overlay chain chain-uri @URI2@ chain-idassert-bind bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials=secret mode=self flags=non-prescriptive The comment say "no chain-URI is configured', but the chain-uri is configured. Where is the truth?

1 0

(ITS#7767) Connection not reset when olcDbUri value changed in cn=config (ldap backend)
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) I configure the LDAP backend under a chain overlay to manage ppolicy-forward-updates configuration, the configuration is: dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: top objectClass: olcConfig objectClass: olcChainConfig objectClass: olcOverlayConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbIDAssertBind: bindmethod="simple" binddn="cn=admin,dc=example,dc=com" crede ntials="secret" mode="none" olcDbUri: ldap://localhost:389 When changing the value of olcDbUri trough an LDAP client, the connection to the server is not reset, so the configuration is not taken dynamically. All is ok if I restart OpenLDAP.

1 0

(ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) I have a simple setup with a master (overlay syncprov + overlay ppolicy) and a slave (syncrepl client, overlay ppolicy). 1. I lock my account in the slave 2. I change the description attribute of my account a first time in the master 3. My account is still locked in the slave 4. I change the description attribute of my account a second time in the master 5. My account is no more locked in the slave: the password policy operational attributes pwdFailureTime and pwdAccountUnlockTime were erased by the one of the master Seems like a control is done the first time that syncrepl update the entry (the first time, pwdAccountLockTime and pwdFailureTime are not erased), but the second time the control is not done.

1 0

(ITS#7765) Crash when adding syncrepl configuration in cn=config without search base
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) When adding an olcSyncrepl attribute in my cn=config, OpenLDAP crashed. The syslog output is: Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 BIND dn="cn=config" method=128 Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 RESULT tag=97 err=0 text= Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=1 MOD dn="olcDatabase={2}mdb,cn=config" Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=1 MOD attr=olcaccess olcdbindex olcsyncrepl Dec 16 11:56:42 ader slapd[8707]: olcSyncrepl: value #0: Error: Malformed "syncrepl" line in slapd config file, missing searchbase. Dec 16 11:56:42 ader slapd[8707]: failed to add syncinfo Dec 16 11:56:42 ader slapd[8707]: ch_calloc of 1 elems of 0 bytes failed I have no gdb trace to give for now, if you think it is required, I will try to find time to do it. But it should be easy to reproduce the issue on your side.

1 0

Re: (ITS#7764) RFE: library lber method which returns the ber size even if the ber is overflown
by hyc＠symas.com 15 Dec '13

15 Dec '13

nhosoi(a)gmail.com wrote: > Full_Name: Noriko Hosoi > Version: 2.4.35-4 > OS: Fedora 18 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.132.181.86) > > > We use the OpenLdap library in our software. LDAP clients could send too large > ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. We'd like to > learn how large the ber size we should prepare from the error. When we look > into the BerElement ber using gdb, ber->ber_len stores the value. But the value > is not returned to the caller when the API fails, e.g., by the overflow. Could > it be possible to have a way to retrieve the ber size under any condition? That doesn't sound like OpenLDAP, we have no LBER_OVERFLOW error code. Nor do we have any particular size limits on a BerElement, other than fitting into a long. -- -- 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#7763) undefined references during LTO enabled build
by nheghathivhistha＠gmail.com 14 Dec '13

14 Dec '13

Hello, Thank you. Markus Trippelsdorf told me in my bug report (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505) what is the problem cause and how to solve it - it is not existing support for slim-LTO-model in binutils. AS=gcc-as AR=gcc-ar NM=gcc-nm RANLIB=gcc-ranlib did it for me for Openldap package in Gentoo too . Best regards, David. 2013/12/13 Howard Chu <hyc(a)symas.com>: > nheghathivhistha(a)gmail.com wrote: >> >> Full_Name: David Kredba >> Version: 2.4.38 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.101.228.82) >> >> >> I am trying to rebuild my system with LTO enabled gcc. >> >> Compilation of Gentoo package /net-nds/openldap-2.4.38-r1 ended with: > > > You cut off the trace just at the crucial line. It should say, e.g.: > > ar ru librewrite.a config.o context.o info.o ldapmap.o map.o params.o rule.o > session.o subst.o var.o xmap.o version.o > ar: creating librewrite.a > > Anyway, I see no build errors here. Closing this ITS. Ask for help on the > -technical mailing list. > >> x86_64-pc-linux-gnu-ar: creating librewrite.a >> /bin/bash ../../libtool --mode=link x86_64-pc-linux-gnu-gcc -O2 -ggdb >> -pipe >> -march=native -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE >> -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb >> -pipe >> -march=native -mtune=native -flto=4 -fuse-linker-plugin -o rewrite >> rewrite.o >> parse.o librewrite.a ../../libraries/liblutil/liblutil.a >> ../../libraries/libldap_r/libldap_r.la ../../libraries/liblber/liblber.la >> -lssl -lcrypto -lcrypt -lresolv -pthread >> libtool: link: x86_64-pc-linux-gnu-gcc -O2 -ggdb -pipe -march=native >> -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE -Wl,-O1 >> -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native >> -mtune=native -flto=4 -fuse-linker-plugin -o .libs/rewrite rewrite.o >> parse.o >> -pthread -Wl,--as-needed librewrite.a ../../libraries/liblutil/liblutil.a >> ../../libraries/libldap_r/.libs/libldap_r.so >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/liblber/.libs/liblber.so >> ../../libraries/liblber/.libs/liblber.so -lssl -lcrypto -lcrypt -lresolv >> -pthread >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: >> In >> function `rewrite_read': >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/parse.c:112: >> undefined reference to `rewrite_parse' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: >> In >> function `main': >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:141: >> undefined reference to `lutil_atoix' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: >> In >> function `apply': >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:52: >> undefined reference to `rewrite_info_init' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:58: >> undefined reference to `rewrite_param_set' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:60: >> undefined reference to `rewrite_session_init' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:75: >> undefined reference to `rewrite_session' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:120: >> undefined reference to `rewrite_session_delete' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:122: >> undefined reference to `rewrite_info_delete' >> collect2: error: ld returned 1 exit status >> Makefile:290: recipe for target 'rewrite' failed >> make[2]: *** [rewrite] Error 1 >> make[2]: Leaving directory >> >> '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite' >> Makefile:296: recipe for target 'all-common' failed >> make[1]: *** [all-common] Error 1 >> make[1]: Leaving directory >> >> '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries' >> Makefile:312: recipe for target 'all-common' failed >> >> Coul you kindly please look into it? I think that header(s) can be missing >> in >> source files and library(ies) at link time. >> >> I uploaded david-kredba-20131213-build.log and >> david-kredba-20131213-config.log >> to your ftp server. >> >> Thank you in advance. >> >> > > > -- > -- 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#7764) RFE: library lber method which returns the ber size even if the ber is overflown
by nhosoi＠gmail.com 13 Dec '13

13 Dec '13

Full_Name: Noriko Hosoi Version: 2.4.35-4 OS: Fedora 18 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.181.86) We use the OpenLdap library in our software. LDAP clients could send too large ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. We'd like to learn how large the ber size we should prepare from the error. When we look into the BerElement ber using gdb, ber->ber_len stores the value. But the value is not returned to the caller when the API fails, e.g., by the overflow. Could it be possible to have a way to retrieve the ber size under any condition?

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