- openldap-bugs - openldap.org

(ITS#6759) assert;Debug -> Debug;assert
by h.b.furuseth＠usit.uio.no 30 Dec '10

30 Dec '10

Full_Name: Hallvard B Furuseth Version: OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard OpenLDAP sometimes does assert() before Debug(). assert is more convenient after Debug, so more info is readily available for debugging. Except when the assert catches that Debug would crash. I'll update some cases, including for soon-to-be-committed asserts.

1 0

(ITS#6758) Cleaning up SlapReply usage
by h.b.furuseth＠usit.uio.no 30 Dec '10

30 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: Linux x86_64 URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Slapd and its modules put varous info in SlapReply and send it. They do not always clean it up afterwards, or not correctly. Then they sometimes reuse the SlapReply without reinitializing, even though most of its fields are invalid at that point. (In practice they are usually mostly zeroed by then, so slapd works anyway.) This is a dup of the misnamed ITS#5340, so the CHANGES file can refer to an ITS with a better name for all the upcoming commits. Also I'll go about it a bit backwards than discussed there: First reset some flags and avoid reusing SlapReply, then get more aggressive about obeying the flag settings that remain.

1 0

(ITS#6757) SASL canonicalize doesn't work as documented
by b.candler＠pobox.com 30 Dec '10

30 Dec '10

Full_Name: Brian Candler Version: 2.4.21 OS: Ubuntu 10.04.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.114.104.19) DOcumentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI gives two example authorization DNs built from SASL/GSSAPI: "a user with the Kerberos principal kurt(a)EXAMPLE.COM would have the associated DN: uid=kurt,cn=example.com,cn=gssapi,cn=auth and the principal ursula/admin(a)FOREIGN.REALM would have the associated DN: uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth" Experimentation shows that the actual behaviour is different. (1) If the realm of the client is the same as the default_realm on the server, then the auth DN is uid=kurt,cn=<olcSaslRealm>,cn=gssapi,cn=auth (2) If the realm of the client is different to the default_realm on the server, then the auth DN is uid=ursula/admin(a)foreign.realm,cn=<olcSaslRealm>,cn=gssapi,cn=auth (If olcSaslRealm is unset in the config then cn=<olcSaslRealm> is omitted entirely) Some real examples are shown below. I reproduced this in a cross-realm auth setup with two MIT Kerberos 1.8.1 KDCs. The realms are WS.NSRC.ORG and REALM3.WS.NSRC.ORG. The server is host noc.ws.nsrc.org and is in realm WS.NSRC.ORG. It has a keytab for ldap/noc.ws.nsrc.org(a)WS.NSRC.ORG, and has olcSaslRealm: EXAMPLE.COM (which is just a junk realm, but it makes it clear that this isn't used for authentication) When a client presents a ticket for inst(a)WS.NSRC.ORG: do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=<continuing> datalen=32 SASL Canonicalize [conn=1000]: authcid="inst" slap_sasl_getdn: conn 1000 id=inst [len=4] => ldap_dn2bv(16) <= ldap_dn2bv(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth >>> dnNormalize: <uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth> => ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0) <= ldap_bv2dn(uid=inst,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=inst,cn=example.com,cn=gssapi,cn=auth)=0 <<< dnNormalize: <uid=inst,cn=example.com,cn=gssapi,cn=auth> ==>slap_sasl2dn: converting SASL name uid=inst,cn=example.com,cn=gssapi,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=1000]: slapAuthcDN="uid=inst,cn=example.com,cn=gssapi,cn=auth" SASL proxy authorize [conn=1000]: authcid="inst(a)EXAMPLE.COM" authzid="inst(a)EXAMPLE.COM" SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/GSSAPI bind: dn="uid=inst,cn=example.com,cn=gssapi,cn=auth" sasl_ssf=56 When a client presents a ticket for student(a)REALM3.WS.NSRC.ORG: do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=<continuing> datalen=32 SASL Canonicalize [conn=1000]: authcid="student(a)REALM3.WS.NSRC.ORG" slap_sasl_getdn: conn 1000 id=student(a)REALM3.WS.NSRC.ORG [len=26] => ldap_dn2bv(16) <= ldap_dn2bv(uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth >>> dnNormalize: <uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth> => ldap_bv2dn(uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth,0) <= ldap_bv2dn(uid=student(a)REALM3.WS.NSRC.ORG,cn=EXAMPLE.COM,cn=GSSAPI,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth)=0 <<< dnNormalize: <uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth> ==>slap_sasl2dn: converting SASL name uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=1000]: slapAuthcDN="uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth" SASL proxy authorize [conn=1000]: authcid="student(a)REALM3.WS.NSRC.ORG" authzid="student(a)REALM3.WS.NSRC.ORG" SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/GSSAPI bind: dn="uid=student(a)realm3.ws.nsrc.org,cn=example.com,cn=gssapi,cn=auth" sasl_ssf=56 You can see that the authcid from libsasl omits the realm when it's the same as the server's, and includes the realm when it's different. However openldap does not split out into "uid=ursula/admin,cn=foreign.realm" as the documentation says. You could treat this either as a behaviour error or a documentation error - if the latter, the olcSaslRealm is pretty useless, because if set it appears in all auth DNs (for both local and foreign realms)

1 0

Re: (ITS#6756) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by jgilmour＠brightcove.com 30 Dec '10

30 Dec '10

--90e6ba211d7d01d52c0498a713c3 Content-Type: text/plain; charset=ISO-8859-1 oops, sorry, this is a duplicate On Thu, Dec 30, 2010 at 4:06 PM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6756. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6756) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6756) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6756 > > Please remember to retain your issue tracking number (ITS#6756) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > > -- Josh Gilmour | Windows Systems & Network Administrator Brightcove, Inc. www.brightcove.com One Cambridge Center, 12th Floor, Cambridge, MA 02142 P: 617.395.5843 F: 617.395.8352 ++++++++++ Brightcove PLAY 2011 Global Customer Conference May 23-25, Boston Seaport Hotel & World Trade Center Registration Now Open: http://brightcove.com/play2011 ++++++++++ --90e6ba211d7d01d52c0498a713c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable oops, sorry, this is a duplicate <div class=3D"gmail_quote">On Thu, = Dec 30, 2010 at 4:06 PM, <<a href=3D"mailto:openldap-= its(a)openldap.org">openldap-its(a)openldap.org</a>> wrote: <block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex;"> *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. =A0Your report has been assigned the tracking number ITS#6756. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. =A0They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. =A0Note that any mail sent to <a href=3D"mailto:openldap-its@openldap.org">openldap-its@= openldap.org</a> with (ITS#6756) in the subject will automatically be attached to the issue report. =A0 =A0 =A0 =A0mailto:<a href=3D"mailto:openldap-its@openldap.org">openlda= p-its(a)openldap.org</a>?subject=3D(ITS#6756) You may follow the progress of this report by loading the following URL in a web browser: =A0 =A0<a href=3D"http://www.OpenLDAP.org/its/index.cgi?findid=3D6756" tar= get=3D"_blank">http://www.OpenLDAP.org/its/index.cgi?findid=3D6756</a> Please remember to retain your issue tracking number (ITS#6756) on any further messages you send to us regarding this report. =A0If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. =A0 =A0 =A0 =A0<a href=3D"http://www.OpenLDAP.org/support/" target=3D"_bla= nk">http://www.OpenLDAP.org/support/</a> -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. </blockquote></div> -- Josh Gilmour | Windows = Systems & Network Administrator Brightcove, Inc. <a href=3D"http= ://www.brightcove.com">www.brightcove.com</a> One Cambridge Center, 12th= Floor, Cambridge, MA 02142 P: 617.395.5843 F: 617.395.8352 ++++++++++ Brightcove PLAY 2= 011 Global Customer Conference May 23-25, Boston Seaport Hotel &= World Trade Center Registration Now Open: <a href=3D"http://brightc= ove.com/play2011">http://brightcove.com/play2011</a> ++++++++++ --90e6ba211d7d01d52c0498a713c3--

1 0

(ITS#6756) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by jgilmour＠techsmog.com 30 Dec '10

30 Dec '10

Full_Name: Josh Gilmour Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14) OS: CentOS release 5.4 32bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.112.23.58) I get a segfault when using the following command and applying a filter file. If we remove the -f, the command runs properly. It doesn't seem to be a major security issue (or one at all, I'm not sure), but it does seem to be a bug I believe... the file i'm using for the -f parameter, 'testing', just has the letter 'a' in it. Here is the process output from gdb: [jgilmour@xijgilmour ~]$ gdb ldapsearch GNU gdb Fedora (6.8-37.el5) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found) (gdb) r -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E pr=1/noprompt -w password -b "OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f testing Starting program: /usr/bin/ldapsearch -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E pr=1/noprompt -w password -b "OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f testing (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) dn: OU=xxx,DC=xxx,DC=LOCAL objectClass: top objectClass: organizationalUnit ou: xxx distinguishedName: OU=xxx,DC=xxx,DC=LOCAL instanceType: 4 whenCreated: 20050103174000.0Z whenChanged: 20081117191042.0Z uSNCreated: 12371 uSNChanged: 6388825 name: xxx objectGUID:: qjRiugCNd0eXyrXkHlETpA== objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=xxx,D C=LOCAL dSCorePropagationData: 20080818221029.0Z dSCorePropagationData: 20080628202026.0Z dSCorePropagationData: 20070611215308.0Z dSCorePropagationData: 20070611213209.0Z dSCorePropagationData: 16010714223649.0Z *** glibc detected *** /usr/bin/ldapsearch: double free or corruption (!prev): 0x086a35f8 *** Program received signal SIGSEGV, Segmentation fault. 0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6 (gdb) i r eax 0x169 361 ecx 0xd43170 13906288 edx 0x86a35f0 141178352 ebx 0xd41ff4 13901812 esp 0xbf9a7078 0xbf9a7078 ebp 0xbf9a713c 0xbf9a713c esi 0x168 360 edi 0xb7fdb000 -1208111104 eip 0xc67a3f 0xc67a3f <_int_malloc+703> eflags 0x210283 [ CF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) bt #0 0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6 #1 0x00c69a1e in malloc () from /lib/i686/nosegneg/libc.so.6 #2 0x00235998 in _dl_map_object () from /lib/ld-linux.so.2 #3 0x0023ead1 in dl_open_worker () from /lib/ld-linux.so.2 #4 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2 #5 0x0023e4b2 in _dl_open () from /lib/ld-linux.so.2 #6 0x00d08072 in do_dlopen () from /lib/i686/nosegneg/libc.so.6 #7 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2 #8 0x00d08225 in __libc_dlopen_mode () from /lib/i686/nosegneg/libc.so.6 #9 0x00ce44d9 in init () from /lib/i686/nosegneg/libc.so.6 #10 0x00ce4673 in backtrace () from /lib/i686/nosegneg/libc.so.6 #11 0x00c5ee51 in __libc_message () from /lib/i686/nosegneg/libc.so.6 #12 0x00c671d5 in _int_free () from /lib/i686/nosegneg/libc.so.6 #13 0x00c67619 in free () from /lib/i686/nosegneg/libc.so.6 #14 0x00c55756 in fclose@@GLIBC_2.1 () from /lib/i686/nosegneg/libc.so.6 #15 0x0804ca88 in ?? () #16 0x00c12e9c in __libc_start_main () from /lib/i686/nosegneg/libc.so.6 #17 0x0804a3f1 in ?? () (gdb) q The program is running. Exit anyway? (y or n) y [jgilmour@xijgilmour ~]$ uname -a Linux xijgilmour.xxx.local 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 20 08:53:10 EST 2010 i686 i686 i386 GNU/Linux

1 0

(ITS#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8
by jgilmour＠techsmog.com 30 Dec '10

30 Dec '10

Full_Name: Josh Gilmour Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14) OS: CentOS release 5.4 32bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (38.112.23.58) I get a segfault when using the following command and applying a filter file. If we remove the -f, the command runs properly. It doesn't seem to be a major security issue (or one at all, I'm not sure), but it does seem to be a bug I believe... the file i'm using for the -f parameter, 'testing', just has the letter 'a' in it. Here is the process output from gdb: [jgilmour@xijgilmour ~]$ gdb ldapsearch GNU gdb Fedora (6.8-37.el5) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found) (gdb) r -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E pr=1/noprompt -w password -b "OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f testing Starting program: /usr/bin/ldapsearch -x -LLL -h xxx.local -D "xxx(a)xxx.local" -E pr=1/noprompt -w password -b "OU=xxx,dc=xxx,dc=local" -S sAMAccountName -f testing (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) dn: OU=xxx,DC=xxx,DC=LOCAL objectClass: top objectClass: organizationalUnit ou: xxx distinguishedName: OU=xxx,DC=xxx,DC=LOCAL instanceType: 4 whenCreated: 20050103174000.0Z whenChanged: 20081117191042.0Z uSNCreated: 12371 uSNChanged: 6388825 name: xxx objectGUID:: qjRiugCNd0eXyrXkHlETpA== objectCategory: CN=Organizational-Unit,CN=Schema,CN=Configuration,DC=xxx,D C=LOCAL dSCorePropagationData: 20080818221029.0Z dSCorePropagationData: 20080628202026.0Z dSCorePropagationData: 20070611215308.0Z dSCorePropagationData: 20070611213209.0Z dSCorePropagationData: 16010714223649.0Z *** glibc detected *** /usr/bin/ldapsearch: double free or corruption (!prev): 0x086a35f8 *** Program received signal SIGSEGV, Segmentation fault. 0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6 (gdb) i r eax 0x169 361 ecx 0xd43170 13906288 edx 0x86a35f0 141178352 ebx 0xd41ff4 13901812 esp 0xbf9a7078 0xbf9a7078 ebp 0xbf9a713c 0xbf9a713c esi 0x168 360 edi 0xb7fdb000 -1208111104 eip 0xc67a3f 0xc67a3f <_int_malloc+703> eflags 0x210283 [ CF SF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) bt #0 0x00c67a3f in _int_malloc () from /lib/i686/nosegneg/libc.so.6 #1 0x00c69a1e in malloc () from /lib/i686/nosegneg/libc.so.6 #2 0x00235998 in _dl_map_object () from /lib/ld-linux.so.2 #3 0x0023ead1 in dl_open_worker () from /lib/ld-linux.so.2 #4 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2 #5 0x0023e4b2 in _dl_open () from /lib/ld-linux.so.2 #6 0x00d08072 in do_dlopen () from /lib/i686/nosegneg/libc.so.6 #7 0x0023ae66 in _dl_catch_error () from /lib/ld-linux.so.2 #8 0x00d08225 in __libc_dlopen_mode () from /lib/i686/nosegneg/libc.so.6 #9 0x00ce44d9 in init () from /lib/i686/nosegneg/libc.so.6 #10 0x00ce4673 in backtrace () from /lib/i686/nosegneg/libc.so.6 #11 0x00c5ee51 in __libc_message () from /lib/i686/nosegneg/libc.so.6 #12 0x00c671d5 in _int_free () from /lib/i686/nosegneg/libc.so.6 #13 0x00c67619 in free () from /lib/i686/nosegneg/libc.so.6 #14 0x00c55756 in fclose@@GLIBC_2.1 () from /lib/i686/nosegneg/libc.so.6 #15 0x0804ca88 in ?? () #16 0x00c12e9c in __libc_start_main () from /lib/i686/nosegneg/libc.so.6 #17 0x0804a3f1 in ?? () (gdb) q The program is running. Exit anyway? (y or n) y [jgilmour@xijgilmour ~]$ uname -a Linux xijgilmour.xxx.local 2.6.18-164.11.1.el5xen #1 SMP Wed Jan 20 08:53:10 EST 2010 i686 i686 i386 GNU/Linux

1 0

(ITS#6754) slapd ignores extra command-line arguments
by rein＠OpenLDAP.org 30 Dec '10

30 Dec '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: Submission from: (NULL) (2a01:600:0:1:129a:ddff:fe4b:9c78) Submitted by: rein slapd silently ignores extra command-line arguments not recognized as options. A simple fix is coming. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6741)
by hyc＠symas.com 30 Dec '10

30 Dec '10

jgcardoso(a)seguridata.com wrote: > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01CBA84D.397A800E > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > I submitted a patch for tls2.c in order to handle DER BitString values. LBER_BITSTRING is already defined in lber.h so there's no need to define LBER_TAG_BITSTRING in your patch. I will clean up some of this and then commit it. -- -- 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#6741)
by jgcardoso＠seguridata.com 30 Dec '10

30 Dec '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CBA84D.397A800E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I submitted a patch for tls2.c in order to handle DER BitString values. =20 This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by SeguriData Privada, S.A. de CV. SeguriData Privada S.A de C. V. has not assigned rights and/or interest in this work to any party. I, Juan Gonzalez Cardoso am authorized by SeguriData Privada, S. A. de C. V., my employer, to release this work under the following terms: =20 The attached modifications to OpenLDAP Software are subject to the following notice: =20 Copyright SeguriData Privada, S. A. de C. V. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. =20 Full_Name: Juan Gonzalez Cardoso Version: 2.4.23 OS: Red Hat 5.5 EL URL: ftp://ftp.openldap.org/incoming/juan-gonzalez-101230.patch =20 =20 =20 =20 ------_=_NextPart_001_01CBA84D.397A800E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 = (filtered medium)"><style></style></head><body lang=3DES-MX link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>I submitted a patch for tls2.c in order to handle DER = BitString values.<o:p></o:p><o:p> </o:p> This patch file is derived from OpenLDAP Software. All of = the modifications to OpenLDAP Software represented in the following = patch(es) were developed by SeguriData Privada, S.A. de = CV.<o:p></o:p>SeguriData Privada S.A de C. V. has not assigned rights = and/or interest in this work to any party.<o:p></o:p>I, Juan Gonzalez Cardoso am = authorized by SeguriData Privada, S. A. de C. V., my employer, to = release this work under the following terms:<o:p></o:p><o:p> </o:p>The attached modifications to = OpenLDAP Software are subject to the following = notice:<o:p></o:p><o:p> </o:p>Copyright = SeguriData Privada, S. A. de C. V.<o:p></o:p>Redistribution and use in source = and binary forms, with or without modification, are permitted only as = authorized by the OpenLDAP Public License.<o:p></o:p><o:p> </o:p>Full_Name: Juan Gonzalez = Cardoso<o:p></o:p>Version: 2.4.23<o:p></o:p>OS: Red Hat 5.5 = EL<o:p></o:p>URL: <a = href=3D"ftp://ftp.openldap.org/incoming/juan-gonzalez-101230.patch">ftp:/= /ftp.openldap.org/incoming/juan-gonzalez-101230.patch</a><o:p></o:p></spa= n><o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p></div></body></html> ------_=_NextPart_001_01CBA84D.397A800E--

1 0

Re: (ITS#6684)
by hyc＠symas.com 30 Dec '10

30 Dec '10

norbert(a)pueschel.net wrote: > Updated TAR-file with (hopefully) sufficient copyright notice... > > http://www.pueschel.net/openldap/norbert-pueschel-autogroup-27102010.tar Your code does a string compare againset "memberOf" to detect those filter references. 1) it should simply be comparing the AttributeDescription pointers 2) since the "memberof" attribute is actually configurable in the memberof overlay, there's no guarantee that this is the correct attribute to be looking for. It should also be configurable in your patch. You're using strcasecmp, but your inputs are already normalized values. You should just use ber_bvcmp. Replying to the original: > 1) Using non-DN-valued URIs for autogroup does not work correctly, even > with the latest version from HEAD. Especially changing group member is > not tracked. I don't see why this should ever work or be supported. LDAP groups list DNs. > 2) Using the memberOf-overlay for constructing autogroups does not work I don't see any reason why this should work. The memberof overlay is not used to construct groups, it is only used to report on group memberships that have already been defined. -- -- 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#6664) Server control forwarding in back_meta and back_ldap
by hyc＠symas.com 30 Dec '10

30 Dec '10

masarati(a)aero.polimi.it wrote: >> Note that the SSSVLV overlay can handle paged results locally too, thus >> negating any need for back-ldap/back-meta to forward it to a remote >> server. >> Obviously for greatest generality, there needs to be a way to configure >> which >> set of controls to pass through, and which to process locally. (Much like >> back-ldap's option to process the WhoAmI exop...) > > Right. With proxies the problem is twofold: > > a) clients request pr because they think they're talking to AD > > b) the proxy may need to use pr even if the client does not request it, > because it knows it's talking to AD > > In (a), the issue could be handled the way sssvlv does, relieving the > proxy from having to deal with server-side pr; this would be extremely > beneficial, for example, for back-meta > > In (b), the proxy could be configured to use pr the way I mentioned above; > in principle, the proxy could be so clever to avoid using pr, and simply > accept to handle unrequested pr responses, but only if instructed to do > so. > > Filtering what controls are passed thru should be easy, since both proxy > backends always call ldap_back_controls_add()/meta_back_controls_add() to > muck with request controls (usually to add proxied authorization and so); > this function could easily strip or add pr if instructed to do so. Should also revisit ITS#4591 while thinking about this. -- -- 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#5966
by hyc＠symas.com 30 Dec '10

30 Dec '10

cn=Monitor does not appear to have this problem any more, at least not for test056 or test039 on my dual-core machine. Can we close this out? -- -- 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#5862) Assert control ignored on non-database entries
by hyc＠symas.com 30 Dec '10

30 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > slapd does not apply the Assert control to non-database entries > (at least the root and subschema entries), yet does not reject > a critical control either. > > I have not explored the magnitutde of the problem: Where the > control can get ignored, and which other controls are ignored. > > $ ldapsearch -LLLx -e\!assert='(objectClass=person)' -b "" -s base > dn: > objectClass: top > objectClass: OpenLDAProotDSE > > $ ldapsearch -LLLx -e\!assert='(objectClass=person)' -b cn=subschema -s base > dn: cn=Subschema > objectClass: top > objectClass: subentry > objectClass: subschema > objectClass: extensibleObject > cn: Subschema > > > -b "" -s sub does apply the control with database bdb + suffix "". > Don't know about back-sql. > However I imagine it varies how careful backends "" are about generating > the root DSE when suffix == "" so controls can be applied to it. Might > need a backend flag which says whether the backend does this, and reject > the critical controls with unwillingToPerform if this flag is not set. With ITS#6753 I've centralized Compare processing into the frontend, so the Assert control is now processed for non-database entries with this op. Someone should take a look and see what other operations we need to worry about. -- -- 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#6741)
by hyc＠symas.com 29 Dec '10

29 Dec '10

The ITS doesn't really handle MIME messages very well. Please just follow the guidelines on the OpenLDAP web site. http://www.openldap.org/devel/contributing.html jgcardoso(a)seguridata.com wrote: > This is a multi-part message in MIME format. > > ------_=_NextPart_001_01CBA7B8.A7EC1D62 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > I created a function to support conversion from DER BitString encoded > data to RFC4517 Bit String Format. > > I tested it alone and it seems to work fine with normal and abnormal > situations. > > =20 > > I also wrote a proposal to the call that must be included at > ldap_X509dn2bv() function. > > =20 > > First comes the conversion function and after comes the proposal. > > =20 > > =20 > > /*****************************************************/ > > =20 > > #define BITS_PER_BYTE 8 > > #define SQUOTE_LENGTH 1 > > #define B_CHAR_LENGTH 1 > > #define STR_OVERHEAD (2*SQUOTE_LENGTH + B_CHAR_LENGTH) > > =20 > > int ldap_der_to_rfc4517_BitString (struct berval *berValue, > > struct berval *rfc4517Value) { > > > ber_len_t bitPadding=3D0; > > ber_len_t bits, maxBits; > > char *tmpStr; > > unsigned char byte; > > ber_len_t bitLength; > > ber_len_t valLen; > > unsigned char* valPtr; > > =20 > > rfc4517Value->bv_len=3D0; > > rfc4517Value->bv_val=3DNULL; > > =20 > > /* Gets padding and points to binary data */ > > valLen=3DberValue->bv_len; > > valPtr=3D(unsigned char*)berValue->bv_val; > > if (valLen) { > > bitPadding=3D(ber_len_t)(valPtr[0]); > > valLen--; > > valPtr++; > > } > > /* If Block is non DER encoding fixes to DER encoding */ > > if (bitPadding>=3D BITS_PER_BYTE) { > > if (valLen*BITS_PER_BYTE> bitPadding ) { > > valLen-=3D(bitPadding/BITS_PER_BYTE); > > bitPadding%=3DBITS_PER_BYTE; > > } else { > > valLen=3D0; > > bitPadding=3D0; > > } > > } > > /* Just in case bad encoding */ > > if (valLen*BITS_PER_BYTE< bitPadding ) { > > bitPadding=3D0; > > valLen=3D0; > > } > > =20 > > /* Gets buffer to hold RFC4517 Bit String format */ > > bitLength=3DvalLen*BITS_PER_BYTE-bitPadding; > > tmpStr=3DLDAP_MALLOC(bitLength + STR_OVERHEAD + 1); > > =20 > > if (!tmpStr) > > return LDAP_NO_MEMORY; > > =20 > > rfc4517Value->bv_val=3DtmpStr; > > rfc4517Value->bv_len=3DbitLength + STR_OVERHEAD; > > =20 > > /* Formatting in '*binary-digit'B format */ > > maxBits=3DBITS_PER_BYTE; > > *tmpStr=3D'\''; > > tmpStr++; > > while(valLen) { > > byte=3D*valPtr; > > if (valLen=3D=3D1) > > maxBits-=3DbitPadding; > > for (bits=3D0; bits<maxBits; bits++) { > > if (0x80& byte) > > *tmpStr=3D'1'; > > else > > *tmpStr=3D'0'; > > tmpStr++; > > byte<<=3D1; > > } > > valPtr++; > > valLen--; > > } > > *tmpStr=3D'\''; > > tmpStr++; > > *tmpStr=3D'B'; > > tmpStr++; > > *tmpStr=3D0; > > =20 > > return LDAP_SUCCESS; > > } > > =20 > > =20 > > /*****************************************************/ > > /*****************************************************/ > > =20 > > =20 > > /* > > * Other tags found in AVAs (X.520) > > */ > > #define LBER_TAG_BITSTRING ((ber_tag_t) 0x03UL) > > =20 > > =20 > > ldap_X509dn2bv function updated: > > =20 > > switch(tag) { > > case LBER_TAG_UNIVERSAL: > > /* This uses 32-bit ISO 10646-1 */ > > csize =3D 4; goto to_utf8; > > case LBER_TAG_BMP: > > /* This uses 16-bit ISO 10646-1 */ > > csize =3D 2; goto to_utf8; > > case LBER_TAG_BITSTRING: > > /* X.690 bitString value converted to RFC4517 Bit > String */ > > rc =3D ldap_der_to_rfc4517_BitString(&Val, > &newAVA->la_value ); > > goto after_utf8; > > case LBER_TAG_TELETEX: > > /* This uses 8-bit, assume ISO 8859-1 */ > > csize =3D 1; > > to_utf8: rc =3D ldap_ucs_to_utf8s(&Val, csize, > &newAVA->la_value ); > > after_utf8: newAVA->la_flags |=3D LDAP_AVA_FREE_VALUE; > > if (rc !=3D LDAP_SUCCESS) goto nomem; > > newAVA->la_flags =3D LDAP_AVA_NONPRINTABLE; > > break; > > case LBER_TAG_UTF8: > > newAVA->la_flags =3D LDAP_AVA_NONPRINTABLE; > > /* This is already in UTF-8 encoding */ > > case LBER_TAG_IA5: > > case LBER_TAG_PRINTABLE: > > /* These are always 7-bit strings */ > > newAVA->la_value =3D Val; > > default: > > ; > > } > > =20 > > > ------_=_NextPart_001_01CBA7B8.A7EC1D62 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = > xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = -- -- 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#6741)
by jgcardoso＠seguridata.com 29 Dec '10

29 Dec '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CBA7B8.A7EC1D62 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I created a function to support conversion from DER BitString encoded data to RFC4517 Bit String Format. I tested it alone and it seems to work fine with normal and abnormal situations. =20 I also wrote a proposal to the call that must be included at ldap_X509dn2bv() function. =20 First comes the conversion function and after comes the proposal. =20 =20 /*****************************************************/ =20 #define BITS_PER_BYTE 8 #define SQUOTE_LENGTH 1 #define B_CHAR_LENGTH 1 #define STR_OVERHEAD (2*SQUOTE_LENGTH + B_CHAR_LENGTH) =20 int ldap_der_to_rfc4517_BitString (struct berval *berValue, struct berval *rfc4517Value) { ber_len_t bitPadding=3D0; ber_len_t bits, maxBits; char *tmpStr; unsigned char byte; ber_len_t bitLength; ber_len_t valLen; unsigned char* valPtr; =20 rfc4517Value->bv_len=3D0; rfc4517Value->bv_val=3DNULL; =20 /* Gets padding and points to binary data */ valLen=3DberValue->bv_len; valPtr=3D(unsigned char*)berValue->bv_val; if (valLen) { bitPadding=3D(ber_len_t)(valPtr[0]); valLen--; valPtr++; } /* If Block is non DER encoding fixes to DER encoding */ if (bitPadding >=3D BITS_PER_BYTE) { if (valLen*BITS_PER_BYTE > bitPadding ) { valLen-=3D(bitPadding/BITS_PER_BYTE); bitPadding%=3DBITS_PER_BYTE; } else { valLen=3D0; bitPadding=3D0; } } /* Just in case bad encoding */ if (valLen*BITS_PER_BYTE < bitPadding ) { bitPadding=3D0; valLen=3D0; } =20 /* Gets buffer to hold RFC4517 Bit String format */ bitLength=3DvalLen*BITS_PER_BYTE-bitPadding; tmpStr=3DLDAP_MALLOC(bitLength + STR_OVERHEAD + 1); =20 if (!tmpStr) return LDAP_NO_MEMORY; =20 rfc4517Value->bv_val=3DtmpStr; rfc4517Value->bv_len=3DbitLength + STR_OVERHEAD; =20 /* Formatting in '*binary-digit'B format */ maxBits=3DBITS_PER_BYTE; *tmpStr=3D'\''; tmpStr++; while(valLen) { byte=3D*valPtr; if (valLen=3D=3D1) maxBits-=3DbitPadding; for (bits=3D0; bits<maxBits; bits++) { if (0x80 & byte) *tmpStr=3D'1'; else *tmpStr=3D'0'; tmpStr++; byte<<=3D1; } valPtr++; valLen--; } *tmpStr=3D'\''; tmpStr++; *tmpStr=3D'B'; tmpStr++; *tmpStr=3D0; =20 return LDAP_SUCCESS; } =20 =20 /*****************************************************/ /*****************************************************/ =20 =20 /* * Other tags found in AVAs (X.520) */ #define LBER_TAG_BITSTRING ((ber_tag_t) 0x03UL) =20 =20 ldap_X509dn2bv function updated: =20 switch(tag) { case LBER_TAG_UNIVERSAL: /* This uses 32-bit ISO 10646-1 */ csize =3D 4; goto to_utf8; case LBER_TAG_BMP: /* This uses 16-bit ISO 10646-1 */ csize =3D 2; goto to_utf8; case LBER_TAG_BITSTRING: /* X.690 bitString value converted to RFC4517 Bit String */ rc =3D ldap_der_to_rfc4517_BitString( &Val, &newAVA->la_value ); goto after_utf8; case LBER_TAG_TELETEX: /* This uses 8-bit, assume ISO 8859-1 */ csize =3D 1; to_utf8: rc =3D ldap_ucs_to_utf8s( &Val, csize, &newAVA->la_value ); after_utf8: newAVA->la_flags |=3D LDAP_AVA_FREE_VALUE; if (rc !=3D LDAP_SUCCESS) goto nomem; newAVA->la_flags =3D LDAP_AVA_NONPRINTABLE; break; case LBER_TAG_UTF8: newAVA->la_flags =3D LDAP_AVA_NONPRINTABLE; /* This is already in UTF-8 encoding */ case LBER_TAG_IA5: case LBER_TAG_PRINTABLE: /* These are always 7-bit strings */ newAVA->la_value =3D Val; default: ; } =20 ------_=_NextPart_001_01CBA7B8.A7EC1D62 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 = (filtered medium)"><style></style></head><body lang=3DES-MX link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>I created a function to = support conversion from DER BitString encoded data to RFC4517 Bit String = Format.<o:p></o:p>I tested it alone and it seems to = work fine with normal and abnormal situations.<o:p></o:p><o:p> </o:p>I also wrote a proposal = to the call that must be included at ldap_X509dn2bv() = function.<o:p></o:p><o:p> </o:p>First comes the conversion function and after comes the = proposal.<o:p></o:p><o:p> </o:p><o:p> </o:p>/*****************************************************/<o:p></o:p><= /span><o:p> </o:p>#define BITS_PER_BYTE     = 8<o:p></o:p>#define = SQUOTE_LENGTH     1<o:p></o:p>#define B_CHAR_LENGTH     = 1<o:p></o:p>#define = STR_OVERHEAD    (2*SQUOTE_LENGTH + = B_CHAR_LENGTH)<o:p></o:p><o:p> </o:p>int = ldap_der_to_rfc4517_BitString (struct berval = *berValue,<o:p></o:p>         =             &= nbsp;           &n= bsp; struct berval *rfc4517Value) = {            =             &= nbsp;        <o:p></o:p>ber_len_t bitPadding=3D0;<o:p></o:p>ber_len_t bits, maxBits;<o:p></o:p>char *tmpStr;<o:p></o:p>unsigned char = byte;<o:p></o:p>ber_len_t = bitLength;<o:p></o:p>ber_len_t = valLen;<o:p></o:p>unsigned char* = valPtr;<o:p></o:p><o:p> </o:p>   rfc4517Value->bv_len=3D0;<o:p></o:p>   = rfc4517Value->bv_val=3DNULL;<o:p></o:p><o:p> </o:p>   /* Gets = padding and points to binary data */<o:p></o:p>   valLen=3DberValue->bv_len;<o:p></o:p>   valPtr=3D(unsigned = char*)berValue->bv_val;<o:p></o:p>   if (valLen) {<o:p></o:p>      = bitPadding=3D(ber_len_t)(valPtr[0]);<o:p></o:p>      valLen--;<o:p></o:p>      valPtr++;<o:p></o:p>   }<o:p></o:p>   /* If = Block is non DER encoding fixes to DER encoding = */<o:p></o:p>   if (bitPadding >=3D = BITS_PER_BYTE) {<o:p></o:p>      if (valLen*BITS_PER_BYTE > = bitPadding ) {<o:p></o:p>         = valLen-=3D(bitPadding/BITS_PER_BYTE);<o:p></o:p>         = bitPadding%=3DBITS_PER_BYTE;<o:p></o:p>      } else {<o:p></o:p>         = valLen=3D0;<o:p></o:p>         = bitPadding=3D0;<o:p></o:p>      }<o:p></o:p>   }<o:p></o:p>   /* Just in = case bad encoding */<o:p></o:p>   if = (valLen*BITS_PER_BYTE < bitPadding ) {<o:p></o:p>      = bitPadding=3D0;<o:p></o:p>      valLen=3D0;<o:p></o:p>   }<o:p></o:p><o:p> </o:p>   /* Gets = buffer to hold RFC4517 Bit String format */<o:p></o:p>   = bitLength=3DvalLen*BITS_PER_BYTE-bitPadding;<o:p></o:p>   tmpStr=3DLDAP_MALLOC(bitLength + STR_OVERHEAD + = 1);<o:p></o:p>   = <o:p></o:p>   if = (!tmpStr)<o:p></o:p>      = return LDAP_NO_MEMORY;<o:p></o:p><o:p> </o:p>   = rfc4517Value->bv_val=3DtmpStr;<o:p></o:p>   rfc4517Value->bv_len=3DbitLength + = STR_OVERHEAD;<o:p></o:p><o:p> </o:p>   /* = Formatting in '*binary-digit'B format */<o:p></o:p>   maxBits=3DBITS_PER_BYTE;<o:p></o:p>   *tmpStr=3D'\'';<o:p></o:p>   tmpStr++;<o:p></o:p>   while(valLen) {<o:p></o:p>      = byte=3D*valPtr;<o:p></o:p>      if = (valLen=3D=3D1)<o:p></o:p>         = maxBits-=3DbitPadding;<o:p></o:p>      for (bits=3D0; bits<maxBits; = bits++) {<o:p></o:p>         if (0x80 & = byte)<o:p></o:p>            = *tmpStr=3D'1';<o:p></o:p>         = else<o:p></o:p>            = *tmpStr=3D'0';<o:p></o:p>         = tmpStr++;<o:p></o:p>         = byte<<=3D1;<o:p></o:p>      }<o:p></o:p>      valPtr++;<o:p></o:p>      valLen--;<o:p></o:p>   }<o:p></o:p>   = *tmpStr=3D'\'';<o:p></o:p>   = tmpStr++;<o:p></o:p>   = *tmpStr=3D'B';<o:p></o:p>   = tmpStr++;<o:p></o:p>   = *tmpStr=3D0;<o:p></o:p><o:p> </o:p>   return = LDAP_SUCCESS;<o:p></o:p>}<o:p></o:p><o:p> </o:p><o:p> </o:p>/*****************************************************/<o:p></o:p><= /span>/*****************************************************/<o:p></o:p><= /span><o:p> </o:p><o:p> </o:p>/*<o:p></o:p> * Other tags = found in AVAs (X.520)<o:p></o:p> = */<o:p></o:p>#define = LBER_TAG_BITSTRING     ((ber_tag_t) = 0x03UL)<o:p></o:p><o:p> </o:p><o:p> </o:p>ldap_X509dn2bv function = updated:<o:p></o:p><o:p> </o:p>           &= nbsp;    switch(tag) {<o:p></o:p>           &= nbsp;    case LBER_TAG_UNIVERSAL:<o:p></o:p>           &= nbsp;         /* This uses = 32-bit ISO 10646-1 */<o:p></o:p>           &= nbsp;         csize =3D 4; goto = to_utf8;<o:p></o:p>           &= nbsp;    case LBER_TAG_BMP:<o:p></o:p>           &= nbsp;         /* This uses = 16-bit ISO 10646-1 */<o:p></o:p>           &= nbsp;         csize =3D 2; goto = to_utf8;<o:p></o:p>         &nb= sp;      case = LBER_TAG_BITSTRING:<o:p></o:p>         &nb= sp;           /* X.690 = bitString value converted to RFC4517 Bit String = */<o:p></o:p>         &nb= sp;           rc =3D = ldap_der_to_rfc4517_BitString( &Val, &newAVA->la_value = );<o:p></o:p>         &nb= sp;           goto = after_utf8;<o:p></o:p>           &= nbsp;    case LBER_TAG_TELETEX:<o:p></o:p>           &= nbsp;         /* This uses = 8-bit, assume ISO 8859-1 */<o:p></o:p>           &= nbsp;         csize =3D = 1;<o:p></o:p>to_utf8:         &nbsp= ;   rc =3D ldap_ucs_to_utf8s( &Val, csize, = &newAVA->la_value );<o:p></o:p>after_utf8:          = newAVA->la_flags |=3D LDAP_AVA_FREE_VALUE;<o:p></o:p>           &= nbsp;         if (rc !=3D = LDAP_SUCCESS) goto nomem;<o:p></o:p>           &= nbsp;         newAVA->la_flags =3D = LDAP_AVA_NONPRINTABLE;<o:p></o:p>           &= nbsp;         break;<o:p></o:p>           &= nbsp;    case LBER_TAG_UTF8:<o:p></o:p>           &= nbsp;         newAVA->la_flags =3D = LDAP_AVA_NONPRINTABLE;<o:p></o:p>           &= nbsp;         /* This is already in = UTF-8 encoding */<o:p></o:p>           &= nbsp;    case LBER_TAG_IA5:<o:p></o:p>           &= nbsp;    case LBER_TAG_PRINTABLE:<o:p></o:p>           &= nbsp;         /* These are = always 7-bit strings */<o:p></o:p>           &= nbsp;         newAVA->la_value =3D = Val;<o:p></o:p>           &= nbsp;    default:<o:p></o:p>           &= nbsp;         ;<o:p></o:p>           &= nbsp;    }<o:p></o:p><o:p> </o:p></div></body></html> ------_=_NextPart_001_01CBA7B8.A7EC1D62--

1 0

Re: (ITS#6745) HEAD emfile race condition -> slapd stopping listening?
by h.b.furuseth＠usit.uio.no 28 Dec '10

28 Dec '10

Howard Chu wrote: >>h.b.furuseth(a)usit.uio.no wrote: >>> Maybe to compensate, slapd_remove() has code which checks if emfile >>> is too big, but nothing checks if it is too small - which looks like >>> slapd might never start listening again. > > On 2nd thought - I don't see how the outcome you describe can occur. If emfile > is non-zero, the list of listeners will be checked for a listener with > non-zero mute status. If any are found, one is guaranteed to be unmuted. But if emfile becomes too small, it reaches zero with a listener still muted - and with emfile = zero, the nothing is unmuted. -- Hallvard

1 0

Re: (ITS#6745) HEAD emfile race condition -> slapd stopping listening?
by hyc＠symas.com 23 Dec '10

23 Dec '10

Howard Chu wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Full_Name: Hallvard B Furuseth >> Version: HEAD >> OS: >> URL: >> Submission from: (NULL) (129.240.6.233) >> Submitted by: hallvard >> >> >> In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support: >> >> slap_listener() protects emfile with slap_daemon[0 ].sd_mutex, >> but slapd_remove() protects it with slap_daemon[id].sd_mutex. >> >> Maybe to compensate, slapd_remove() has code which checks if emfile >> is too big, but nothing checks if it is too small - which looks like >> slapd might never start listening again. On 2nd thought - I don't see how the outcome you describe can occur. If emfile is non-zero, the list of listeners will be checked for a listener with non-zero mute status. If any are found, one is guaranteed to be unmuted. If none are found, emfile will be zeroed. In no case will slapd fail to unmute a listener. -- -- 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#6745) HEAD emfile race condition -> slapd stopping listening?
by hyc＠symas.com 23 Dec '10

23 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support: > > slap_listener() protects emfile with slap_daemon[0 ].sd_mutex, > but slapd_remove() protects it with slap_daemon[id].sd_mutex. > > Maybe to compensate, slapd_remove() has code which checks if emfile > is too big, but nothing checks if it is too small - which looks like > slapd might never start listening again. > > Simplest fix: add this to slapd_remove(): > > if (id) ldap_pvt_thread_mutex_<lock,unlock>(&slap_daemon[0].sd_mutex ); > > slap_daemon[0].sd_mutex looks quite contended that way, though. > Maybe a separate emfile_mutex is better. Alternatively, just skip the check entirely when id != 0. Which would mean that only closing a session on the first listener would ever trigger the other listeners to be unmuted. Doesn't seem so terrible; if slapd is actually out of descriptors one or two connections either way won't make a huge difference in service. -- -- 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#6449) roadmap update
by hyc＠symas.com 23 Dec '10

23 Dec '10

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: NA > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > http://www.openldap.org/software/roadmap.html needs to be updated to note that > OpenLDAP 2.3 is no longer maintained, same as 2.2 and prior. > Fixed in CVS. Kurt, can you refresh the web site? -- -- 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#6453) OpenLDAP memory leak on LDAP_TIMEOUT
by hyc＠symas.com 23 Dec '10

23 Dec '10

alinachegalati(a)yahoo.com wrote: > Full_Name: Alin Vasile > Version: 2.4.19 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.7) > A patch for this is now in CVS HEAD. > > Hi, > > We have a memory leak LDAP_TIMEOUT is encountered on > ldap_search_ext_invocation and we are unable to determine if it is related to > OpenLdap or not. The following summarizes our code in case the LDAP_TIMEOUT > response is returned : > > LDAPMessage *res ; > > // acquire connection > > // perform search > > if(rc == LDAP_TIMEOUT) > { > ldap_msgfree(res); > // return connection > } > > Is ldap_msgfree(res) enough in this case ? > > We tested our program by enabling a low timeout and hence all ldap calls > resulting in timeout. The memory leak is about 9 Megs in several minutes, at a > load of 5 req/ sec. > > dmalloc sees the following not allocated pointers > > 6642692 bytes : Line 640 of "io.c" starts at address 0xff2659c4 > <ber_get_next+468> and ends at 0xff2659cc<ber_get_next+476>. > > 2019876 bytes : Line 277 of "memory.c" starts at address 0xff26676c > <ber_memcalloc_x+132> and ends at 0xff266774<ber_memcalloc_x+140>. > > > -- -- 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#6680) slapd why sasl error message?
by Howard Chu 23 Dec '10

23 Dec '10

>From your log info, your client is obviously using SASL DIGEST-MD5. There is nothing relevant to slapd or the OpenLDAP code here, fix your client if you want these errors to stop. Closing this ITS.

1 0

Fwd: (ITS#6750) About 3rd Party Technical Support Services
by kurt＠OpenLDAP.org 23 Dec '10

23 Dec '10

--Apple-Mail-80--876671303 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: "harrybetter" <harrybetter(a)qq.com> > Date: December 22, 2010 10:32:22 PM PST > To: "Kurt Zeilenga" <kurt(a)openldap.org> > Subject: Re: (ITS#6750) About 3rd Party Technical Support Services > x-spam-status: No, score=3D-0.5 required=3D5.0 = tests=3DBAYES_00,DKIM_SIGNED, = FILL_THIS_FORM_FRAUD_PHISH,FREEMAIL_FROM,FROM_EXCESS_BASE64,HTML_MESSAGE, = RCVD_IN_DNSWL_NONE,T_DKIM_INVALID,T_FILL_THIS_FORM_SHORT,T_RP_MATCHES_RCVD= autolearn=3Dno version=3D3.3.1 >=20 > =20 > anwser is below. >=20 > Please provide the URL for your website/webpage to which your listing = should be linked to? > answer : www.seojindsa.kr >=20 > Please provide a URL to a webpage at your website which details = technical support services=20 > which are specifically tailored to users of OpenLDAP Software? (may be = same as the above URL) > answer : www.seojindsa.kr >=20 > Please provide a summary of your current participation in the OpenLDAP = community? > anwser : Provides consultancy, development, training and user support = for OpenLDAP Software in korea, china. > we will convert openldap document by korean, chinese. >=20 > Please provide an email address (possibly yours) at a domain = registered to SeojinDSA we can use to confirm your association with = SeojinDSA?=20 > answer : sjsong(a)seojindsa.kr=20 >=20 > =20 > =20 > ------------------ Original ------------------ > From: "Kurt Zeilenga"<kurt(a)OpenLDAP.org>; > Date: Thu, Dec 16, 2010 11:36 AM > To: "harrybetter"<harrybetter(a)qq.com>; > Cc: "openldap-its"<openldap-its(a)openldap.org>; > Subject: Re: (ITS#6750) About 3rd Party Technical Support Services > =20 >=20 > On Dec 15, 2010, at 5:27 PM, harrybetter(a)qq.com wrote: >=20 > > Full_Name: Jerry Liu > > Version: openldap-2.4.23 > > OS: RedHatLinux EL5 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (221.0.151.187) > >=20 > >=20 > > We are SeojinDSA CO,LTD. We sincerely hope to show our company = name and link > > on list of "Technical Support" page. But we do not know how to = apply, I hope > > this reply. >=20 > By filing an ITS with your request, you have applied. >=20 > > SeojinDSA is an emerging leader in the Korean field of = next-generation > > Directory Service(LDAP) and Identity Managerment(IAM:Identity Access > > Management????The company's headquarter is in Seoul.Our Company is = made up of > > experts and thought leaders who are recognized for building = world-class > > Directory Service. >=20 > A couple of questions. >=20 > Please provide the URL for your website/webpage to which your listing = should be linked to? > Please provide a URL to a webpage at your website which details = technical support services which are specifically tailored to users of = OpenLDAP Software? (may be same as the above URL) > Please provide a summary of your current participation in the OpenLDAP = community? > Please provide an email address (possibly yours) at a domain = registered to SeojinDSA we can use to confirm your association with = SeojinDSA? If you do not wish this email to be made public (all = openldap-its(a)openldap.org is public), you may send this email address = directly to me at <kurt(a)openldap.org>. >=20 > (It's okay for the above requested URLs to refer to non-English web = pages.) >=20 > Regards, Kurt --Apple-Mail-80--876671303 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "> <div> <div>Begin forwarded message:</div> <blockquote type=3D"cite"><div = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;">From: "harrybetter" = <<a = href=3D"mailto:harrybetter@qq.com">harrybetter(a)qq.com</a>> </= div><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: = 0px; margin-left: 0px;">Date: December 22, 2010 = 10:32:22 PM PST </div><div style=3D"margin-top: 0px; = margin-right: 0px; margin-bottom: 0px; margin-left: 0px;">To: "Kurt Zeilenga" <<a = href=3D"mailto:kurt@openldap.org">kurt(a)openldap.org</a>> </di= v><div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;">Subject: Re: (ITS#6750) = About 3rd Party Technical Support Services </div><div = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;">x-spam-status: = No, score=3D-0.5 required=3D5.0 = tests=3DBAYES_00,DKIM_SIGNED, = FILL_THIS_FORM_FRAUD_PHISH,FREEMAIL_FROM,FROM_EXCESS_BASE64,HTML_MESSAGE, = RCVD_IN_DNSWL_NONE,T_DKIM_INVALID,T_FILL_THIS_FORM_SHORT,T_RP_MATCHES_RCVD= autolearn=3Dno = version=3D3.3.1 </div> <div><includetail> </includetail>= </div> <div> <div style=3D"COLOR: #000"> <div>anwser is = below.Please = provide the URL for your website/webpage to which your listing should be = linked to? answer : <a href=3D"http://www.seojindsa.kr/" = target=3D"_blank">www.seojindsa.kr</a>Please provide a URL to a webpage at your = website which details technical support services which are = specifically tailored to users of OpenLDAP Software? (may be same as the = above URL) answer : <a href=3D"http://www.seojindsa.kr/" = target=3D"_blank">www.seojindsa.kr</a>Please provide a summary of your current = participation in the OpenLDAP community? anwser : Provides = consultancy, development, training and user support for OpenLDAP = Software in korea, china.          = we will convert openldap document by korean, chinese.Please provide an email = address (possibly yours) at a domain registered to SeojinDSA we can use = to confirm your association with SeojinDSA? answer : <a = href=3D"mailto:sjsong@seojindsa.kr" target=3D"_blank">sjsong(a)seojindsa.kr</a> </div> <div> <div> </div> <div> </div> <div style=3D"COLOR: #000"> <div style=3D"PADDING-BOTTOM: 2px; PADDING-LEFT: 0px; PADDING-RIGHT: = 0px; FONT-FAMILY: Arial Narrow; FONT-SIZE: 12px; PADDING-TOP: = 2px">------------------ Original ------------------</div> <div style=3D"PADDING-BOTTOM: 8px; PADDING-LEFT: 8px; PADDING-RIGHT: = 8px; BACKGROUND: #efefef; FONT-SIZE: 12px; PADDING-TOP: 8px"> <div id=3D"menu_sender">From:  "Kurt Zeilenga"<<a = href=3D"mailto:kurt@OpenLDAP.org">kurt(a)OpenLDAP.org</a>>;</div> <div>Date:  Thu, Dec 16, 2010 11:36 AM</div> <div>To:  "harrybetter"<<a = href=3D"mailto:harrybetter@qq.com">harrybetter(a)qq.com</a>>; = </div> <div>Cc:  "openldap-its"<<a = href=3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>&gt= ;; </div> <div>Subject:  Re: (ITS#6750) About 3rd Party Technical = Support Services</div></div> <div> </div> On Dec 15, 2010, at 5:27 PM, <a = href=3D"mailto:harrybetter@qq.com">harrybetter(a)qq.com</a> = wrote: > Full_Name: Jerry Liu > Version: = openldap-2.4.23 > OS: RedHatLinux EL5 > URL: <a = href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/= </a> > Submission from: (NULL) (221.0.151.187) > > = >    We are SeojinDSA CO,LTD. We sincerely hope to show = our company name and link > on list of "Technical Support" page. = But we do not know how to apply, I hope > this reply. By = filing an ITS with your request, you have applied. >  =   SeojinDSA is an emerging leader in the Korean field of = next-generation > Directory Service(LDAP) and Identity = Managerment(IAM:Identity Access > Management????The company's = headquarter is in Seoul.Our Company is made up of > experts and = thought leaders who are recognized for building world-class > = Directory Service. A couple of questions. Please provide = the URL for your website/webpage to which your listing should be linked = to? Please provide a URL to a webpage at your website which details = technical support services which are specifically tailored to users of = OpenLDAP Software? (may be same as the above URL) Please provide a = summary of your current participation in the OpenLDAP = community? Please provide an email address (possibly yours) at a = domain registered to SeojinDSA we can use to confirm your association = with SeojinDSA?  If you do not wish this email to be made public = (all <a = href=3D"mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a> = is public), you may send this email address directly to me at <<a = href=3D"mailto:kurt@openldap.org">kurt(a)openldap.org</a>>. (It's = okay for the above requested URLs to refer to non-English web = pages.) Regards, = Kurt</div></div></div></div></blockquote></div> </body></html>= --Apple-Mail-80--876671303--

1 0

Re: (ITS#6478) slapd crashes with segfault
by hyc＠symas.com 20 Dec '10

20 Dec '10

wolfgang.hummel(a)hp.com wrote: > We had some of this crashes on LDAP slaves in the past: This appears to be due to your custom template overlay. You probably need to check its correctness using a tool like valgrind or Purify. > In /var/log/messages > 2010-12-05T11:22:57.643777+01:00 ts2mstsv001 kernel: 6>slapd[18900000000000= > 0025 rip 0000003be707p 000000 > > Stack trace when crash occurred (search for entry 0xe932208 in back db (BD= > B) response is contained a corrupted address) > #0 0x0000003be7075b50 in strcpy () from /lib64/libc.so.6 > #1 0x00002b5ffe3debeb in template_response (op=3D0xfa01aa0, rs=3D0x4813bc6= > 0) at /usr/include/bits/string3.h:118 > #2 0x00000000004a34eb in over_back_response (op=3D0xfa01aa0, rs=3D0x4813bc= > 60) at ../servers/slapd/backover.c:237 > #3 0x0000000000449865 in slap_response_play (op=3D0xfa01aa0, rs=3D0x4813bc= > 60) at ../servers/slapd/result.c:402 > #4 0x000000000044bfcc in slap_send_search_entry (op=3D0xfa01aa0, rs=3D0x48= > 13bc60) at ../servers/slapd/result.c:887 > #5 0x00000000004b695f in bdb_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at s= > ervers/slapd/back-bdb/search.c:961 > #6 0x00000000004a37c2 in overlay_op_walk (op=3D0xfa01aa0, rs=3D0x4813bc60,= > which=3Dop_search, oi=3D0xe5df160, on=3D0x0) at ../servers/slapd/backover.= > c:669 > #7 0x00000000004a3d58 in over_op_func (op=3D0xfa01aa0, rs=3D0x4813bc60, wh= > ich=3Dop_search) at ../servers/slapd/backover.c:721 > #8 0x000000000043c4e6 in fe_op_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at= > ../servers/slapd/search.c:376 > #9 0x00000000004a37c2 in overlay_op_walk (op=3D0xfa01aa0, rs=3D0x4813bc60,= > which=3Dop_search, oi=3D0xe577ec0, on=3D0x0) at ../servers/slapd/backover.= > c:669 > #10 0x00000000004a3d58 in over_op_func (op=3D0xfa01aa0, rs=3D0x4813bc60, wh= > ich=3Dop_search) at ../servers/slapd/backover.c:721 > #11 0x000000000043cc95 in do_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at ..= > /servers/slapd/search.c:227 > #12 0x0000000000439ff4 in connection_operation (ctx=3D0x4813bdb0, arg_v=3D<= > value optimized out>) at ../servers/slapd/connection.c:1109 > #13 0x000000000043a651 in connection_read_thread (ctx=3D0x4813bdb0, argv=3D= > <value optimized out>) at ../servers/slapd/connection.c:1245 > #14 0x00000000005330a8 in ldap_int_thread_pool_wrapper (xpool=3D0xe546600) = > at ../libraries/libldap_r/tpool.c:685 > #15 0x0000003be7c062e7 in start_thread () from /lib64/libpthread.so.0 > #16 0x0000003be70ce3bd in clone () from /lib64/libc.so.6 > > (gdb) fr 11 > #11 0x000000000043cc95 in do_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at ..= > /servers/slapd/search.c:227 > 227 ../servers/slapd/search.c: No such file or directory. > in ../servers/slapd/search.c > (gdb) p * op > $55 =3D {o_hdr =3D 0xfa01c10, o_tag =3D 99, o_time =3D 1291544577, o_tincr = > =3D 140, o_bd =3D 0x47fb9ea0, o_req_dn =3D {bv_len =3D 41, bv_val =3D 0x102= > 51e00 "ou=3Dcms,ou=3Dprofiles,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, > o_req_ndn =3D {bv_len =3D 41, bv_val =3D 0x10251ee0 "ou=3Dcms,ou=3Dprofil= > es,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, o_request =3D {oq_add =3D {rs_modlist = > =3D 0x2, rs_e =3D 0x500000064}, oq_bind =3D {rb_method =3D 2, > rb_cred =3D {bv_len =3D 21474836580, bv_val =3D 0x0}, rb_edn =3D {bv_= > len =3D 0, bv_val =3D 0x10251fc0 "\020"}, rb_ssf =3D 270868336, rb_mech =3D= > {bv_len =3D 18, > bv_val =3D 0x10251f98 "(uid=3D491710471677)"}}, oq_compare =3D {rs_= > ava =3D 0x2}, oq_modify =3D {rs_mods =3D {rs_modlist =3D 0x2, rs_no_opattrs= > =3D 100 'd'}, rs_increment =3D 0}, oq_modrdn =3D { > rs_mods =3D {rs_modlist =3D 0x2, rs_no_opattrs =3D 100 'd'}, rs_delet= > eoldrdn =3D 0, rs_newrdn =3D {bv_len =3D 0, bv_val =3D 0x10251fc0 "\020"}, = > rs_nnewrdn =3D {bv_len =3D 270868336, > bv_val =3D 0x12<Address 0x12 out of bounds>}, rs_newSup =3D 0x1025= > 1f98, rs_nnewSup =3D 0x0}, oq_search =3D {rs_scope =3D 2, rs_deref =3D 0, r= > s_slimit =3D 100, rs_tlimit =3D 5, > rs_limit =3D 0x0, rs_attrsonly =3D 0, rs_attrs =3D 0x10251fc0, rs_fil= > ter =3D 0x10251f70, rs_filterstr =3D {bv_len =3D 18, bv_val =3D 0x10251f98 = > "(uid=3D491710471677)"}}, oq_abandon =3D { > rs_msgid =3D 2}, oq_cancel =3D {rs_msgid =3D 2}, oq_extended =3D {rs_= > reqoid =3D {bv_len =3D 2, bv_val =3D 0x500000064<Address 0x500000064 out o= > f bounds>}, rs_flags =3D 0, rs_reqdata =3D 0x0}, > oq_pwdexop =3D {rs_extended =3D {rs_reqoid =3D {bv_len =3D 2, bv_val = > =3D 0x500000064<Address 0x500000064 out of bounds>}, rs_flags =3D 0, rs_re= > qdata =3D 0x0}, rs_old =3D {bv_len =3D 270868416, > bv_val =3D 0x10251f70 "=A3"}, rs_new =3D {bv_len =3D 18, bv_val =3D= > 0x10251f98 "(uid=3D491710471677)"}, rs_mods =3D 0x0, rs_modtail =3D 0x0}},= > o_abandon =3D 0, o_cancel =3D 0, o_groups =3D 0x0, > o_do_not_cache =3D 0 '\0', o_is_auth_check =3D 0 '\0', o_dont_replicate = > =3D 0 '\0', o_acl_priv =3D ACL_NONE, o_nocaching =3D 0 '\0', o_delete_glue_= > parent =3D 0 '\0', o_no_schema_check =3D 0 '\0', > o_no_subordinate_glue =3D 0 '\0', o_ctrlflag =3D '\0'<repeats 31 times>,= > o_controls =3D 0xfa01d58, o_authz =3D {sai_method =3D 128, sai_mech =3D {b= > v_len =3D 0, bv_val =3D 0x0}, sai_dn =3D { > bv_len =3D 51, bv_val =3D 0x2aaab89f0a50 "uid=3Dadmin,ou=3Dcms,ou=3Dp= > rofiles,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, sai_ndn =3D {bv_len =3D 51, > bv_val =3D 0x2aaab8a04e20 "uid=3Dadmin,ou=3Dcms,ou=3Dprofiles,ou=3Dmm= > o,c=3Dde,o=3Dvodafone"}, sai_ssf =3D 0, sai_transport_ssf =3D 0, sai_tls_ss= > f =3D 0, sai_sasl_ssf =3D 0}, o_ber =3D 0x2aaac8098630, > o_res_ber =3D 0x0, o_callback =3D 0x4813a740, o_ctrls =3D 0x0, o_csn =3D = > {bv_len =3D 0, bv_val =3D 0x0}, o_private =3D 0x0, o_extra =3D {slh_first = > =3D 0x4813a480}, o_next =3D {stqe_next =3D 0x0}} > (gdb) p * rs > $56 =3D {sr_type =3D REP_SEARCH, sr_tag =3D 0, sr_msgid =3D 0, sr_err =3D 0= > , sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr= > _un =3D {sru_search =3D {r_entry =3D 0xe932208, > r_attr_flags =3D 17, r_operational_attrs =3D 0x0, r_attrs =3D 0x10251= > fc0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0xe93= > 2208}, sru_extended =3D { > r_rspoid =3D 0xe932208 "\2002\a", r_rspdata =3D 0x11}}, sr_flags =3D = > 4} > > Frame analysis (function called) > (gdb) fr 0 > #0 0x0000003be7075b50 in strcpy () from /lib64/libc.so.6 > (gdb) info registers > rax 0x1 1 > rbx 0x1 1 > rcx 0x3 3 > rdx 0x47f37648 1207137864 > rsi 0x25 37 > rdi 0x47f37648 1207137864 > rbp 0x47f265e4 0x47f265e4 > rsp 0x47a25518 0x47a25518 > r8 0xfefefefefefefeff -72340172838076673 > r9 0x4813bdd0 1209253328 > r10 0x2aaab8000020 46912719814688 > r11 0x206 518 > r12 0xe5e2ae0 241052384 > r13 0x0 0 > r14 0xfa01aa0 262150816 > r15 0x6 6 > rip 0x3be7075b50 0x3be7075b50<strcpy+16> > eflags 0x10217 [ CF PF AF IF RF ] > cs 0x33 51 > ss 0x2b 43 > ds 0x0 0 > es 0x0 0 > fs 0x63 99 > gs 0x0 0 > (gdb) disas=20 > Dump of assembler code for function strcpy: > 0x0000003be7075b40<strcpy+0>: mov %rsi,%rcx > 0x0000003be7075b43<strcpy+3>: and $0x7,%ecx > 0x0000003be7075b46<strcpy+6>: mov %rdi,%rdx > 0x0000003be7075b49<strcpy+9>: je 0x3be7075b66<strcpy+38> > 0x0000003be7075b4b<strcpy+11>: neg %ecx > 0x0000003be7075b4d<strcpy+13>: add $0x8,%ecx > 0x0000003be7075b50<strcpy+16>: mov (%rsi),%al > > rsi is a parameter of strcpy.=20 > rsi should be an address but we have 0x25 which is an invalid address. So c= > rash 2010-12-05T11:22:57.643777+01:00 ts2mstsv001 kernel: 6>slapd[189000000= > 000000025 rip 0000003be707p 000000 > rsi is not modified in strcpy, then, check rsi calculation in template_resp= > onse > > (gdb) fr 1 > #1 0x00002b5ffe3debeb in template_response (op=3D0xfa01aa0, rs=3D0x4813bc6= > 0) at /usr/include/bits/string3.h:118 > 118 return __builtin___strcpy_chk (__dest, __src, __bos (__dest)); > (gdb) info registers > rax 0x1 1 > rbx 0x1 1 > rcx 0x3 3 > rdx 0x47f37648 1207137864 > rsi 0x25 37 > rdi 0x47f37648 1207137864 > rbp 0x47f265e4 0x47f265e4 > rsp 0x47a25520 0x47a25520 > r8 0xfefefefefefefeff -72340172838076673 > r9 0x4813bdd0 1209253328 > r10 0x2aaab8000020 46912719814688 > r11 0x206 518 > r12 0xe5e2ae0 241052384 > r13 0x0 0 > r14 0xfa01aa0 262150816 > r15 0x6 6 > rip 0x2b5ffe3debeb 0x2b5ffe3debeb<template_response+3787> > eflags 0x10217 [ CF PF AF IF RF ] > cs 0x33 51 > ss 0x2b 43 > ds 0x0 0 > es 0x0 0 > fs 0x63 99 > gs 0x0 0 > > (gdb) disass 0x00002b5ffe3debeb > Dump of assembler code for function template_response: > ... > 0x00002b5ffe3deb86<template_response+3686>: lea 0x5010c4(%rsp),%rbp > 0x00002b5ffe3deb8e<template_response+3694>: xor %r15d,%r15d > 0x00002b5ffe3deb91<template_response+3697>: xor %r13d,%r13d > 0x00002b5ffe3deb94<template_response+3700>: mov %rdx,0x30(%rsp) > 0x00002b5ffe3deb99<template_response+3705>: mov %rcx,0x28(%rsp) > 0x00002b5ffe3deb9e<template_response+3710>: jmp 0x2b5ffe3dec07<temp= > late_response+3815> > 0x00002b5ffe3deba0<template_response+3712>: mov 0x511900(%rsp),%rax > 0x00002b5ffe3deba8<template_response+3720>: test %rax,%rax > 0x00002b5ffe3debab<template_response+3723>: je 0x2b5ffe3debeb<temp= > late_response+3787> > 0x00002b5ffe3debad<template_response+3725>: mov 0x8(%rax),%rsi > 0x00002b5ffe3debb1<template_response+3729>: test %rsi,%rsi > 0x00002b5ffe3debb4<template_response+3732>: je 0x2b5ffe3debeb<temp= > late_response+3787> > 0x00002b5ffe3debb6<template_response+3734>: cmpq $0x7ff,(%rax) > 0x00002b5ffe3debbd<template_response+3741>: ja 0x2b5ffe3df966<temp= > late_response+7238> > 0x00002b5ffe3debc3<template_response+3747>: movslq 0x512124(%rsp),%rdi > 0x00002b5ffe3debcb<template_response+3755>: mov 0x28(%rsp),%rdx > 0x00002b5ffe3debd0<template_response+3760>: lea 0x1(%rdi),%eax > 0x00002b5ffe3debd3<template_response+3763>: shl $0xb,%rdi > 0x00002b5ffe3debd7<template_response+3767>: lea 0x808(%rdi,%rdx,1),%= > rdi > 0x00002b5ffe3debdf<template_response+3775>: mov %eax,0x512124(%rsp) > 0x00002b5ffe3debe6<template_response+3782>: callq 0x2b5ffe3dc688<strc= > py@plt> > 0x00002b5ffe3debeb<template_response+3787>: lea 0x1(%r13),%eax > (gdb) p *(long **)($rsp+0x511900) > $17 =3D (long *) 0x2aaab4859d00 > (gdb) x/20x 0x2aaab4859d00 > 0x2aaab4859d00: 0x00000000 0x00000000 0x00000025 0x00000000 > > rsi is broken, not a valid address. > > > Wolfgang Hummel > > > -- -- 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#6747) LDAP_CONNECTIONLESS nitpicks
by Kurt＠OpenLDAP.org 20 Dec '10

20 Dec '10

On Dec 20, 2010, at 2:51 AM, Hallvard B Furuseth wrote: > Kurt(a)OpenLDAP.org writes: >> My nitpick regarding this feature is that it still exists. :-) >=20 > Actually there still are complaints that OpenLDAP has lost cldap - = from > people trying to get Windows/Samba to cooperate with OpenLDAP. That's MSCLDAP not CLDAP. Just another nitpick. > Windows > apparently sends a cldap message as an "LDAP ping". > http://ubuntuforums.org/showthread.php?t=3D673292 > http://onemansjourneyintolinux.blogspot.com/2008/06/cldap.html >=20 > Personally I only compiled it since it exists - I randomize my config > options a bit now and then for testing. I suggest that those that care about MSCLDAP or CLDAP, submit patches to = correct any issues they with its implementation. Continuing bitrot, to = me, is an indication that the code should be removed. -- Kurt=

1 0

Re: (ITS#6747) LDAP_CONNECTIONLESS nitpicks
by h.b.furuseth＠usit.uio.no 20 Dec '10

20 Dec '10

Kurt(a)OpenLDAP.org writes: > My nitpick regarding this feature is that it still exists. :-) Actually there still are complaints that OpenLDAP has lost cldap - from people trying to get Windows/Samba to cooperate with OpenLDAP. Windows apparently sends a cldap message as an "LDAP ping". http://ubuntuforums.org/showthread.php?t=673292 http://onemansjourneyintolinux.blogspot.com/2008/06/cldap.html Personally I only compiled it since it exists - I randomize my config options a bit now and then for testing. -- Hallvard

1 0

(ITS#6753) Compare operation broken with attribute inheritance
by h.b.furuseth＠usit.uio.no 20 Dec '10

20 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (193.157.200.213) Submitted by: hallvard back-bdb, back-monitor: If attr A is ACL-protected and inherits from B, one can still check its value with ldapcompare ... 'B:value'. back-config: Compare doesn't seem to support attribute inheritance. root DSE, cn=subschema: Inheritance works correctly. ######## acl.conf include servers/slapd/schema/core.schema rootdse root.ldif access to attrs=st,cn by * none access to * by * read database bdb suffix o=foo directory acl.dir dbconfig set_flags DB_LOG_AUTOREMOVE database monitor database config access to * by * read ######## root.ldif dn: objectClass: extensibleObject st: hidden ######## slapadd: acl.ldif dn: o=foo objectClass: organization st: hidden ######## Results. cn=config should get TRUE, others UNDEFINED. ldapcompare -x cn=config name:config -> UNDEFINED, No such attribute (16) ldapcompare -x cn=config cn:config -> TRUE ldapcompare -x o=foo name:hidden -> TRUE ldapcompare -x o=foo st:hidden -> UNDEFINED, Insufficient access (50) ldapcompare -x cn=monitor name:monitor -> TRUE ldapcompare -x cn=monitor cn:monitor -> UNDEFINED, Insufficient access (50) ldapcompare -x '' name:hidden -> UNDEFINED, Insufficient access (50) ldapcompare -x '' cn:hidden -> UNDEFINED, Insufficient access (50) ldapcompare -x cn=subschema cn:subschema ->UNDEFINED,Insufficient access (50) ldapcompare -x cn=subschema name:subschema ->UNDEFINED,Insufficient access (50)

1 0

(ITS#6752) slapo-dynlist issues
by h.b.furuseth＠usit.uio.no 20 Dec '10

20 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: Submission from: (NULL) (193.157.200.213) Submitted by: hallvard Dynlist Compare operation: - dynlist_compare() can use an entry after it has been released. It thinks that clearing rs->sr_entry prevents a search from releasing the entry, even after the search completes. Not so. Dynlist mostly worked anyway, I think because dynlist itself follows this expectation for entries without REP_ENTRY_MODIFIABLE which it has duplicated. That includes entries it receives directly from back-bdb. - dynlist_compare() can do needless work: search the same entry several times, fetch an entry to search in a backend which does not support searching, find authz for an entry which will not be searched. - dynlist_sc_save_entry() could read rs->sr_entry when rs->sr_type != REP_SEARCH, which means some other part of the union may be in use. Search operation: - dynlist_sc_update() did not clear REP_ENTRY_MODIFIABLE when freeing. - dynlist_prepare_entry() did not honor REP_ENTRY_MUSTRELEASE. OpenLDAP 2.2/2.3 compatibility code: - Can be dropped, recent dynlist.c does not compile on these versions. Fixing. Simplest Compare fix will ignore errors from o.o_bd->be_search(), just like dynlist_prepare_entry() does.

1 0

Re: (ITS#6478) slapd crashes with segfault
by wolfgang.hummel＠hp.com 19 Dec '10

19 Dec '10

We had some of this crashes on LDAP slaves in the past: In /var/log/messages 2010-12-05T11:22:57.643777+01:00 ts2mstsv001 kernel: 6>slapd[18900000000000= 0025 rip 0000003be707p 000000 Stack trace when crash occurred (search for entry 0xe932208 in back db (BD= B) response is contained a corrupted address) #0 0x0000003be7075b50 in strcpy () from /lib64/libc.so.6 #1 0x00002b5ffe3debeb in template_response (op=3D0xfa01aa0, rs=3D0x4813bc6= 0) at /usr/include/bits/string3.h:118 #2 0x00000000004a34eb in over_back_response (op=3D0xfa01aa0, rs=3D0x4813bc= 60) at ../servers/slapd/backover.c:237 #3 0x0000000000449865 in slap_response_play (op=3D0xfa01aa0, rs=3D0x4813bc= 60) at ../servers/slapd/result.c:402 #4 0x000000000044bfcc in slap_send_search_entry (op=3D0xfa01aa0, rs=3D0x48= 13bc60) at ../servers/slapd/result.c:887 #5 0x00000000004b695f in bdb_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at s= ervers/slapd/back-bdb/search.c:961 #6 0x00000000004a37c2 in overlay_op_walk (op=3D0xfa01aa0, rs=3D0x4813bc60,= which=3Dop_search, oi=3D0xe5df160, on=3D0x0) at ../servers/slapd/backover.= c:669 #7 0x00000000004a3d58 in over_op_func (op=3D0xfa01aa0, rs=3D0x4813bc60, wh= ich=3Dop_search) at ../servers/slapd/backover.c:721 #8 0x000000000043c4e6 in fe_op_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at= ../servers/slapd/search.c:376 #9 0x00000000004a37c2 in overlay_op_walk (op=3D0xfa01aa0, rs=3D0x4813bc60,= which=3Dop_search, oi=3D0xe577ec0, on=3D0x0) at ../servers/slapd/backover.= c:669 #10 0x00000000004a3d58 in over_op_func (op=3D0xfa01aa0, rs=3D0x4813bc60, wh= ich=3Dop_search) at ../servers/slapd/backover.c:721 #11 0x000000000043cc95 in do_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at ..= /servers/slapd/search.c:227 #12 0x0000000000439ff4 in connection_operation (ctx=3D0x4813bdb0, arg_v=3D<= value optimized out>) at ../servers/slapd/connection.c:1109 #13 0x000000000043a651 in connection_read_thread (ctx=3D0x4813bdb0, argv=3D= <value optimized out>) at ../servers/slapd/connection.c:1245 #14 0x00000000005330a8 in ldap_int_thread_pool_wrapper (xpool=3D0xe546600) = at ../libraries/libldap_r/tpool.c:685 #15 0x0000003be7c062e7 in start_thread () from /lib64/libpthread.so.0 #16 0x0000003be70ce3bd in clone () from /lib64/libc.so.6 (gdb) fr 11 #11 0x000000000043cc95 in do_search (op=3D0xfa01aa0, rs=3D0x4813bc60) at ..= /servers/slapd/search.c:227 227 ../servers/slapd/search.c: No such file or directory. in ../servers/slapd/search.c (gdb) p * op $55 =3D {o_hdr =3D 0xfa01c10, o_tag =3D 99, o_time =3D 1291544577, o_tincr = =3D 140, o_bd =3D 0x47fb9ea0, o_req_dn =3D {bv_len =3D 41, bv_val =3D 0x102= 51e00 "ou=3Dcms,ou=3Dprofiles,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, o_req_ndn =3D {bv_len =3D 41, bv_val =3D 0x10251ee0 "ou=3Dcms,ou=3Dprofil= es,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, o_request =3D {oq_add =3D {rs_modlist = =3D 0x2, rs_e =3D 0x500000064}, oq_bind =3D {rb_method =3D 2, rb_cred =3D {bv_len =3D 21474836580, bv_val =3D 0x0}, rb_edn =3D {bv_= len =3D 0, bv_val =3D 0x10251fc0 "\020"}, rb_ssf =3D 270868336, rb_mech =3D= {bv_len =3D 18, bv_val =3D 0x10251f98 "(uid=3D491710471677)"}}, oq_compare =3D {rs_= ava =3D 0x2}, oq_modify =3D {rs_mods =3D {rs_modlist =3D 0x2, rs_no_opattrs= =3D 100 'd'}, rs_increment =3D 0}, oq_modrdn =3D { rs_mods =3D {rs_modlist =3D 0x2, rs_no_opattrs =3D 100 'd'}, rs_delet= eoldrdn =3D 0, rs_newrdn =3D {bv_len =3D 0, bv_val =3D 0x10251fc0 "\020"}, = rs_nnewrdn =3D {bv_len =3D 270868336, bv_val =3D 0x12 <Address 0x12 out of bounds>}, rs_newSup =3D 0x1025= 1f98, rs_nnewSup =3D 0x0}, oq_search =3D {rs_scope =3D 2, rs_deref =3D 0, r= s_slimit =3D 100, rs_tlimit =3D 5, rs_limit =3D 0x0, rs_attrsonly =3D 0, rs_attrs =3D 0x10251fc0, rs_fil= ter =3D 0x10251f70, rs_filterstr =3D {bv_len =3D 18, bv_val =3D 0x10251f98 = "(uid=3D491710471677)"}}, oq_abandon =3D { rs_msgid =3D 2}, oq_cancel =3D {rs_msgid =3D 2}, oq_extended =3D {rs_= reqoid =3D {bv_len =3D 2, bv_val =3D 0x500000064 <Address 0x500000064 out o= f bounds>}, rs_flags =3D 0, rs_reqdata =3D 0x0}, oq_pwdexop =3D {rs_extended =3D {rs_reqoid =3D {bv_len =3D 2, bv_val = =3D 0x500000064 <Address 0x500000064 out of bounds>}, rs_flags =3D 0, rs_re= qdata =3D 0x0}, rs_old =3D {bv_len =3D 270868416, bv_val =3D 0x10251f70 "=A3"}, rs_new =3D {bv_len =3D 18, bv_val =3D= 0x10251f98 "(uid=3D491710471677)"}, rs_mods =3D 0x0, rs_modtail =3D 0x0}},= o_abandon =3D 0, o_cancel =3D 0, o_groups =3D 0x0, o_do_not_cache =3D 0 '\0', o_is_auth_check =3D 0 '\0', o_dont_replicate = =3D 0 '\0', o_acl_priv =3D ACL_NONE, o_nocaching =3D 0 '\0', o_delete_glue_= parent =3D 0 '\0', o_no_schema_check =3D 0 '\0', o_no_subordinate_glue =3D 0 '\0', o_ctrlflag =3D '\0' <repeats 31 times>,= o_controls =3D 0xfa01d58, o_authz =3D {sai_method =3D 128, sai_mech =3D {b= v_len =3D 0, bv_val =3D 0x0}, sai_dn =3D { bv_len =3D 51, bv_val =3D 0x2aaab89f0a50 "uid=3Dadmin,ou=3Dcms,ou=3Dp= rofiles,ou=3Dmmo,c=3Dde,o=3Dvodafone"}, sai_ndn =3D {bv_len =3D 51, bv_val =3D 0x2aaab8a04e20 "uid=3Dadmin,ou=3Dcms,ou=3Dprofiles,ou=3Dmm= o,c=3Dde,o=3Dvodafone"}, sai_ssf =3D 0, sai_transport_ssf =3D 0, sai_tls_ss= f =3D 0, sai_sasl_ssf =3D 0}, o_ber =3D 0x2aaac8098630, o_res_ber =3D 0x0, o_callback =3D 0x4813a740, o_ctrls =3D 0x0, o_csn =3D = {bv_len =3D 0, bv_val =3D 0x0}, o_private =3D 0x0, o_extra =3D {slh_first = =3D 0x4813a480}, o_next =3D {stqe_next =3D 0x0}} (gdb) p * rs $56 =3D {sr_type =3D REP_SEARCH, sr_tag =3D 0, sr_msgid =3D 0, sr_err =3D 0= , sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr= _un =3D {sru_search =3D {r_entry =3D 0xe932208, r_attr_flags =3D 17, r_operational_attrs =3D 0x0, r_attrs =3D 0x10251= fc0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0xe93= 2208}, sru_extended =3D { r_rspoid =3D 0xe932208 "\2002\a", r_rspdata =3D 0x11}}, sr_flags =3D = 4} Frame analysis (function called) (gdb) fr 0 #0 0x0000003be7075b50 in strcpy () from /lib64/libc.so.6 (gdb) info registers rax 0x1 1 rbx 0x1 1 rcx 0x3 3 rdx 0x47f37648 1207137864 rsi 0x25 37 rdi 0x47f37648 1207137864 rbp 0x47f265e4 0x47f265e4 rsp 0x47a25518 0x47a25518 r8 0xfefefefefefefeff -72340172838076673 r9 0x4813bdd0 1209253328 r10 0x2aaab8000020 46912719814688 r11 0x206 518 r12 0xe5e2ae0 241052384 r13 0x0 0 r14 0xfa01aa0 262150816 r15 0x6 6 rip 0x3be7075b50 0x3be7075b50 <strcpy+16> eflags 0x10217 [ CF PF AF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x63 99 gs 0x0 0 (gdb) disas=20 Dump of assembler code for function strcpy: 0x0000003be7075b40 <strcpy+0>: mov %rsi,%rcx 0x0000003be7075b43 <strcpy+3>: and $0x7,%ecx 0x0000003be7075b46 <strcpy+6>: mov %rdi,%rdx 0x0000003be7075b49 <strcpy+9>: je 0x3be7075b66 <strcpy+38> 0x0000003be7075b4b <strcpy+11>: neg %ecx 0x0000003be7075b4d <strcpy+13>: add $0x8,%ecx 0x0000003be7075b50 <strcpy+16>: mov (%rsi),%al rsi is a parameter of strcpy.=20 rsi should be an address but we have 0x25 which is an invalid address. So c= rash 2010-12-05T11:22:57.643777+01:00 ts2mstsv001 kernel: 6>slapd[189000000= 000000025 rip 0000003be707p 000000 rsi is not modified in strcpy, then, check rsi calculation in template_resp= onse (gdb) fr 1 #1 0x00002b5ffe3debeb in template_response (op=3D0xfa01aa0, rs=3D0x4813bc6= 0) at /usr/include/bits/string3.h:118 118 return __builtin___strcpy_chk (__dest, __src, __bos (__dest)); (gdb) info registers rax 0x1 1 rbx 0x1 1 rcx 0x3 3 rdx 0x47f37648 1207137864 rsi 0x25 37 rdi 0x47f37648 1207137864 rbp 0x47f265e4 0x47f265e4 rsp 0x47a25520 0x47a25520 r8 0xfefefefefefefeff -72340172838076673 r9 0x4813bdd0 1209253328 r10 0x2aaab8000020 46912719814688 r11 0x206 518 r12 0xe5e2ae0 241052384 r13 0x0 0 r14 0xfa01aa0 262150816 r15 0x6 6 rip 0x2b5ffe3debeb 0x2b5ffe3debeb <template_response+3787> eflags 0x10217 [ CF PF AF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x63 99 gs 0x0 0 (gdb) disass 0x00002b5ffe3debeb Dump of assembler code for function template_response: ... 0x00002b5ffe3deb86 <template_response+3686>: lea 0x5010c4(%rsp),%rbp 0x00002b5ffe3deb8e <template_response+3694>: xor %r15d,%r15d 0x00002b5ffe3deb91 <template_response+3697>: xor %r13d,%r13d 0x00002b5ffe3deb94 <template_response+3700>: mov %rdx,0x30(%rsp) 0x00002b5ffe3deb99 <template_response+3705>: mov %rcx,0x28(%rsp) 0x00002b5ffe3deb9e <template_response+3710>: jmp 0x2b5ffe3dec07 <temp= late_response+3815> 0x00002b5ffe3deba0 <template_response+3712>: mov 0x511900(%rsp),%rax 0x00002b5ffe3deba8 <template_response+3720>: test %rax,%rax 0x00002b5ffe3debab <template_response+3723>: je 0x2b5ffe3debeb <temp= late_response+3787> 0x00002b5ffe3debad <template_response+3725>: mov 0x8(%rax),%rsi 0x00002b5ffe3debb1 <template_response+3729>: test %rsi,%rsi 0x00002b5ffe3debb4 <template_response+3732>: je 0x2b5ffe3debeb <temp= late_response+3787> 0x00002b5ffe3debb6 <template_response+3734>: cmpq $0x7ff,(%rax) 0x00002b5ffe3debbd <template_response+3741>: ja 0x2b5ffe3df966 <temp= late_response+7238> 0x00002b5ffe3debc3 <template_response+3747>: movslq 0x512124(%rsp),%rdi 0x00002b5ffe3debcb <template_response+3755>: mov 0x28(%rsp),%rdx 0x00002b5ffe3debd0 <template_response+3760>: lea 0x1(%rdi),%eax 0x00002b5ffe3debd3 <template_response+3763>: shl $0xb,%rdi 0x00002b5ffe3debd7 <template_response+3767>: lea 0x808(%rdi,%rdx,1),%= rdi 0x00002b5ffe3debdf <template_response+3775>: mov %eax,0x512124(%rsp) 0x00002b5ffe3debe6 <template_response+3782>: callq 0x2b5ffe3dc688 <strc= py@plt> 0x00002b5ffe3debeb <template_response+3787>: lea 0x1(%r13),%eax (gdb) p *(long **)($rsp+0x511900) $17 =3D (long *) 0x2aaab4859d00 (gdb) x/20x 0x2aaab4859d00 0x2aaab4859d00: 0x00000000 0x00000000 0x00000025 0x00000000 rsi is broken, not a valid address. Wolfgang Hummel

1 0

Re: (ITS#6478) slapd crashes with segfault
by hyc＠symas.com 18 Dec '10

18 Dec '10

wolfgang.hummel(a)hp.com wrote: > We managed to install it with debug-symbols now, > but did not have a new crash (yet). > > However we did a deeper anaylysis of existing > crashes. > Here is the outcome: > #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 > (gdb) thread apply all bt > > Thread 3 (process 17892): > #0 0x00000037a5a075a5 in pthread_join () from /lib64/libpthread.so.0 > #1 0x000000000043402c in slapd_daemon () at ../../../servers/slapd/daemon.= > c:2834 > #2 0x0000000000420d75 in main (argc=3D5, argv=3D0x7fff3a6ee4b8) at ../../.= > ./servers/slapd/main.c:953 > > Thread 2 (process 17894): > #0 0x00000037a5a0a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/lib= > pthread.so.0 > #1 0x000000000052fdab in ldap_pvt_thread_pool_destroy (tpool=3D0x8635e8, r= > un_pending=3D487320688) at ../../../libraries/libldap_r/tpool.c:558 > #2 0x000000000043767c in slapd_daemon_task (ptr=3D<value optimized out>) a= > t ../../../servers/slapd/daemon.c:2764 > #3 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 > #4 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 > > Thread 1 (process 17895): > #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 > #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 > #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 > #3 0x00000037a4e6f444 in _int_free () from /lib64/libc.so.6 > #4 0x00000037a4e72a6c in free () from /lib64/libc.so.6 > #5 0x0000000000559e07 in sb_rdahead_remove (sbiod=3D0x2aaac488d0d0) at ../= > ../../libraries/liblber/sockbuf.c:606 > #6 0x0000000000559fb9 in ber_sockbuf_free (sb=3D0x2aaac488d0d0) at ../../.= > ./libraries/liblber/sockbuf.c:71 > #7 0x0000000000000000 in ?? () This is quite unlikely to be a valid trace, since sb_rdahead_remove is only used on UDP sockets, and UDP socket support is not enabled by default nor is there a configure switch to enable it. -- -- 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#6751) 3rd Party Technical Support Services
by Kurt＠OpenLDAP.org 17 Dec '10

17 Dec '10

A listing for New Elements GmbH has been added. Please check it for = errors. You are welcomed to suggest changes, though note that we prefer = to keep the listings reasonably concise. In your suggested listing, it = wasn't clear to me which URL you wished me to use in your listing (only = one is allowed). If you like the other to be used, please indicate so. Regards, Kurt=

1 0

Re: (ITS#6751) 3rd Party Technical Support Services
by Kurt＠OpenLDAP.org 16 Dec '10

16 Dec '10

On Dec 16, 2010, at 4:36 AM, d.pietratus(a)newelements.de wrote: > Full_Name: David Pietratus - New Elements GmbH > Version:=20 > OS:=20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (188.111.114.162) >=20 >=20 > Dear OpenLDAP team, >=20 > We would like to appear in the 3rd Party Technical Support Services=20 > area at the OpenLDAP websitehttp://www.openldap.org/support/ > For over 10 years, IT-Schulungen.com is a recognized hotspot for many = companies > and authorities when it comes to the implementation of IT training and = IT > management in Germany, Austria and Switzerland. The portfolio of = seminars > reaches from software development, databases over network technologies = and > portals to open source technologies. One of our goals is to promote = open source > topics. > We offer OpenLDAP trainings for overview and advanced users as well as = a large > selection of other open source technologies. >=20 > We would like to appear in the 3rd Party Technical Support Services = area at the > OpenLDAP websitehttp://www.openldap.org/support/ with the following = content and > link: >=20 > http://www.it-schulungen.com - Germany IT-Schulungen.com offers=20 > OpenLDAP trainings from project experienced trainers as well as other = open > source technologies. > http://www.it-schulungen.com/seminare/opensource/openldap/index.html Your request appears to contain all the information needed for it to be = considered. The OpenLDAP Engineering Team will now consider your = application. If further information is needed, you will be contacted. = You can expect a some action (accept, deny, or defer for more = information) to be taken within the next week. Please note that if your listing is accepted it will be listed with the = heading: New Elements GmbH (IT-Shulungen.com) - Germany and with both firm name and the service name with both linked to = http://www.it-schulungen.com. The descriptive text will likely be = modified to match the style of writing of other listings. Regards, Kurt

1 0

(ITS#6751) 3rd Party Technical Support Services
by d.pietratus＠newelements.de 16 Dec '10

16 Dec '10

Full_Name: David Pietratus - New Elements GmbH Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.111.114.162) Dear OpenLDAP team, We would like to appear in the 3rd Party Technical Support Services area at the OpenLDAP websitehttp://www.openldap.org/support/ For over 10 years, IT-Schulungen.com is a recognized hotspot for many companies and authorities when it comes to the implementation of IT training and IT management in Germany, Austria and Switzerland. The portfolio of seminars reaches from software development, databases over network technologies and portals to open source technologies. One of our goals is to promote open source topics. We offer OpenLDAP trainings for overview and advanced users as well as a large selection of other open source technologies. We would like to appear in the 3rd Party Technical Support Services area at the OpenLDAP websitehttp://www.openldap.org/support/ with the following content and link: http://www.it-schulungen.com - Germany IT-Schulungen.com offers OpenLDAP trainings from project experienced trainers as well as other open source technologies. http://www.it-schulungen.com/seminare/opensource/openldap/index.html

1 0

Re: (ITS#6750) About 3rd Party Technical Support Services
by kurt＠OpenLDAP.org 15 Dec '10

15 Dec '10

On Dec 15, 2010, at 5:27 PM, harrybetter(a)qq.com wrote: > Full_Name: Jerry Liu > Version: openldap-2.4.23 > OS: RedHatLinux EL5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (221.0.151.187) >=20 >=20 > We are SeojinDSA CO,LTD. We sincerely hope to show our company name = and link > on list of "Technical Support" page. But we do not know how to apply, = I hope > this reply. By filing an ITS with your request, you have applied. > SeojinDSA is an emerging leader in the Korean field of = next-generation > Directory Service(LDAP) and Identity Managerment(IAM:Identity Access > Management=A3=A9The company's headquarter is in Seoul.Our Company is = made up of > experts and thought leaders who are recognized for building = world-class > Directory Service. A couple of questions. Please provide the URL for your website/webpage to which your listing = should be linked to? Please provide a URL to a webpage at your website which details = technical support services which are specifically tailored to users of = OpenLDAP Software? (may be same as the above URL) Please provide a summary of your current participation in the OpenLDAP = community? Please provide an email address (possibly yours) at a domain registered = to SeojinDSA we can use to confirm your association with SeojinDSA? If = you do not wish this email to be made public (all = openldap-its(a)openldap.org is public), you may send this email address = directly to me at <kurt(a)openldap.org>. (It's okay for the above requested URLs to refer to non-English web = pages.) Regards, Kurt=

1 0

(ITS#6750) About 3rd Party Technical Support Services
by harrybetter＠qq.com 15 Dec '10

15 Dec '10

Full_Name: Jerry Liu Version: openldap-2.4.23 OS: RedHatLinux EL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (221.0.151.187) We are SeojinDSA CO,LTD. We sincerely hope to show our company name and link on list of "Technical Support" page. But we do not know how to apply, I hope this reply. SeojinDSA is an emerging leader in the Korean field of next-generation Directory Service(LDAP) and Identity Managerment(IAM:Identity Access Management£©The company's headquarter is in Seoul.Our Company is made up of experts and thought leaders who are recognized for building world-class Directory Service.

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by cmikk＠qwest.net 15 Dec '10

15 Dec '10

On Sun, Dec 12, 2010 at 06:22:38PM +0100, Rein Tollevik wrote: > On 11/19/10 23:55 , cmikk(a)qwest.net wrote: > > >will evaluate to true in cases where it should not. A quick fix would be to > >compare directly against the CSN of the sessionlog's head: > > An extended version of this fix, which also ensures that the > sessionlog is kept in csn order, is now in head. Please test, > syncprov.c revision 1.320. Looks good to me. Thank you. I discovered this bug while trying to reproduce ITS#6717. I've attached a patch to that ITS which appears to fix that problem. If you have the time, I'd appreciate some feedback on that patch. The issue makes it very inefficient to run a slave in refreshOnly mode with a multimaster / mirrormode master. Best Regards, -- Chris Mikkelson | It has been said that man is a rational animal. cmikk(a)qwest.net | All my life I have been searching for evidence | which could support this. -- Bertrand Russell

1 0

(ITS#6717) patch for syncprov unnecessary presentation issue
by cmikk＠qwest.net 15 Dec '10

15 Dec '10

The following patch against servers/slapd/overlays/syncprov.c version 1.320 appears to fix the issue detailed in ITS#6717, and does not appear to break any of the basic sync functionality. --- syncprov.c.1.320 2010-12-15 19:55:32.000000000 +0000 +++ syncprov.c 2010-12-15 22:13:48.000000000 +0000 @@ -2409,7 +2409,7 @@ sync_control *srs; BerVarray ctxcsn; int i, *sids, numcsns; - struct berval mincsn; + struct berval mincsn, maxcsn; int dirty = 0; if ( !(op->o_sync_mode & SLAP_SYNC_REFRESH) ) return SLAP_CB_CONTINUE; @@ -2524,12 +2524,25 @@ i++; } - /* Find the smallest CSN */ - mincsn = srs->sr_state.ctxcsn[0]; - for ( i=1; i<srs->sr_state.numcsns; i++ ) { - if ( ber_bvcmp( &mincsn, &srs->sr_state.ctxcsn[i] ) > 0 ) - mincsn = srs->sr_state.ctxcsn[i]; + /* Find the smallest CSN which differs between cookie + * and contextCSN. + */ + mincsn.bv_len = 0; + maxcsn.bv_len = 0; + for ( i=0; i<srs->sr_state.numcsns; i++) { + for (j=0; j<numcsns; j++) { + if ( srs->sr_state.sids[i] != sids[j] ) continue; + if (BER_BVISNULL(&maxcsn) || ber_bvcmp( &maxcsn, &srs->sr_state.ctxcsn[i] ) < 0 ) { + maxcsn = srs->sr_state.ctxcsn[i]; + } + if (ber_bvcmp( &srs->sr_state.ctxcsn[i], &ctxcsn[j] ) < 0) { + if (BER_BVISNULL(&mincsn) || ber_bvcmp( &mincsn, &srs->sr_state.ctxcsn[i] ) > 0 ) { + mincsn = srs->sr_state.ctxcsn[i]; + } + } + } } + if (BER_BVISNULL(&mincsn)) mincsn = maxcsn; /* If nothing has changed, shortcut it */ if ( srs->sr_state.numcsns == numcsns ) {

1 0

(ITS#6749) Shut up "configure monitor database to enable"
by h.b.furuseth＠usit.uio.no 15 Dec '10

15 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Please don't give the "configure monitor database to enable" message by default. Either just remove it, or better, stop cn=config from adding a default olcMonitoring: TRUE attribute to olcDatabase objects. (The flag value can still default to True if the attribute is absent.) Then you can give the message if the _admin_ has explicitly asked for monitoring, instead of if slapd has asked for it.

1 0

Re: (ITS#6747) LDAP_CONNECTIONLESS nitpicks
by Kurt＠OpenLDAP.org 14 Dec '10

14 Dec '10

My nitpick regarding this feature is that it still exists. :-) -- Kurt On Dec 14, 2010, at 6:04 AM, h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Bug: > slapd/daemon.c outputs a berval instead of berval.bv_val. > > Compiler warnings: > slapd/connection.c needs lber-int.h for ber_int_sb_read(). > libldap/<abandon.c, search.c> pass a struct sockaddr* to a char*. > > Fixing.

1 0

Re: (ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by ralf＠OpenLDAP.org 14 Dec '10

14 Dec '10

Hi, Am Dienstag 14 Dezember 2010, 12:15:04 schrieb De Bonis Hamelin, Marie Antoinette (Marian - CMS): > Hi, > > Could you please confirm/share us, modifications like moving from > strcpy() to memcpy() were done also for the bdb back-end? If yes, > could you also give us in which release fixes were committed? As mentioned in a previous comment in this ITS the fix is in r1.169 of back-bdb/dn2id.c. Back-bdb didn't need a separate fix as this issue was back-hdb specific. Otherwise it would most probably not need an extra fix as well as back-bdb and back-hdb share most of their code. -- regards, Ralf

1 0

(ITS#6748) slapo-memberof can log scrambled error text
by h.b.furuseth＠usit.uio.no 14 Dec '10

14 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard memberof_value_modify() calls op->o_bd->be_modify( &op2, &rs2 ); and then uses rs2.sr_text, which can be a value on be_modify's stack. Fixing by deleting 'text=...' from the error message.

1 0

(ITS#6747) LDAP_CONNECTIONLESS nitpicks
by h.b.furuseth＠usit.uio.no 14 Dec '10

14 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Bug: slapd/daemon.c outputs a berval instead of berval.bv_val. Compiler warnings: slapd/connection.c needs lber-int.h for ber_int_sb_read(). libldap/<abandon.c, search.c> pass a struct sockaddr* to a char*. Fixing.

1 0

Re: (ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 14 Dec '10

14 Dec '10

I've fixed it in HEAD, unless early errors in translucent_search() should be ignored or filter errors should NOT be ignored. -- Hallvard

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 13 Dec '10

13 Dec '10

Could we have this overlay in contrib/ shipped with 2.4.24? That would be really nice. I've tested it with 2.4.23 and it still seems to work.

1 0

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by rmeggins＠redhat.com 13 Dec '10

13 Dec '10

On 12/10/2010 09:03 PM, Howard Chu wrote: > rmeggins(a)redhat.com wrote: >> I "rebased" the patch on top of a recent change: >> revision 1.24 >> date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 >> -17 >> ITS#6625 Remove some LDAP_R_COMPILEs > > I didn't quite understand the point of the discussion of SSLv2 clients > in the comments on this patch, but committed it anyway. Thanks. I usually defer to Bob Relyea - he insists this is secure, and will not use SSLv2 if it is explicitly disabled (which it is in the OpenLDAP implementation). > > I would hope that nobody is still using SSLv2 these days. Also if a > StartTLS request fails, then the rest of the code in tlsm.c should > never even be reached; the TLS sockbuf layer wouldn't be installed. In my testing, openldap server was calling the tls session_accept function after the client failed to start tls. Because the failure was on the client side (e.g. a bogus CA cert), the server left the connection flagged with c_needs_tls_accept, and called ldap_pvt_tls_accept() on the next read. I've confirmed this using both openldap 2.4 with openssl and with moznss. openssl also checks for sslv2 incoming connections, but handles error cases better (e.g. it looks for http connections), including the case where the header bytes don't match a known sslv2, v3, or tls handshake. See ssl23_get_client_hello() for more information. > >> The new patch is here: >> ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… >> >> >> This patch file is derived from OpenLDAP Software. All of the >> modifications to OpenLDAP Software represented in the following >> patch(es) were developed by Red Hat. Red Hat has not assigned rights >> and/or interest in this work to any party. I, Rich Megginson am >> authorized by Red Hat, my employer, to release this work under the >> following terms. >> >> Red Hat hereby place the following modifications to OpenLDAP Software >> (and only these modifications) into the public domain. Hence, these >> modifications may be freely used and/or redistributed for any purpose >> with or without attribution and/or other notice. >> >> >> >> > >

1 0

Re: (ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

I wrote: > translucent_search() can return LDAP_COMPARE_FALSE from test_filter(). ...and other error codes too. Should it ignore all other result codes from test_filter() than LDAP_COMPARE_TRUE? -- Hallvard

1 0

(ITS#6746) broken slapo-translucent failure handling
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard translucent_search() can return LDAP_COMPARE_FALSE from test_filter(). Should presumably be LDAP_SUCCESS. It should probably either ignore rc from overlay_op_walk() or not. Currently it ignores rc only if there are entries in tc.list. It doesn't seem to free the remaining entries in tc.list after send_search_entry() failure.

1 0

(ITS#6745) HEAD emfile race condition -> slapd stopping listening?
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard In HEAD slapd/daemon.c, thanks to HEAD's multiple listener support: slap_listener() protects emfile with slap_daemon[0 ].sd_mutex, but slapd_remove() protects it with slap_daemon[id].sd_mutex. Maybe to compensate, slapd_remove() has code which checks if emfile is too big, but nothing checks if it is too small - which looks like slapd might never start listening again. Simplest fix: add this to slapd_remove(): if (id) ldap_pvt_thread_mutex_<lock,unlock>( &slap_daemon[0].sd_mutex ); slap_daemon[0].sd_mutex looks quite contended that way, though. Maybe a separate emfile_mutex is better.

1 0

Re: (ITS#6476) Failure to delete entry with multi-master replication
by piotr.tarnowski＠us.edu.pl 13 Dec '10

13 Dec '10

Hi! We have observed similiar symptoms with OpenLDAP 2.4.23: 2010-12-10T14:56:45+01:00 ldapst2/192.168.10.48 slapd[29363]: [ID 502419 local4.debug] Entry uid=Replicator,dc=us,dc=edu,dc=pl CSN 2 0101208130342.415481Z#000000#008#000000 older or equal to ctx 20101208130342.415481Z#000000#008#000000 2010-12-10T14:56:45+01:00 ldapst2/192.168.10.48 slapd[29363]: [ID 653192 local4.debug] syncprov_search_response: cookie=rid=008,sid= 008,csn=20101202144622.962136Z#000000#007#000000;20101001125631.576652Z#000000#003#000000;20101210135344.096897Z#000000#008#000000 do you have any fixes? Regards -- [ Piotr Tarnowski piotr.tarnowski(a)us.edu.pl ] [ Unix Administrator, University of Silesia, Katowice, Poland ]

1 0

Re: (ITS#6731) Scrambled error strings from back-ldif
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

Howard Chu writes: > It is not an error in ldif_back_add() since rs->sr_text is only used by > send_ldap_result(). Its value upon return from ldif_back_add is irrelevant. Should have been true but isn't - a number of modules reuse SlapReply variables without clearing them:-( -- Hallvard

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by h.b.furuseth＠usit.uio.no 13 Dec '10

13 Dec '10

I suppose it could be old misnamed ITS#5340. If so, try http://folk.uio.no/hbf/OpenLDAP/slapreply-draft3.diff Compile with CPPFLAGS="-DRS_USE_ASSERT=0". If that helps, the patch needs to work without the CPPFLAGS, but the asserts may be overeager. -- Hallvard

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 12 Dec '10

12 Dec '10

On 11/19/10 23:55 , cmikk(a)qwest.net wrote: > will evaluate to true in cases where it should not. A quick fix would be to > compare directly against the CSN of the sessionlog's head: An extended version of this fix, which also ensures that the sessionlog is kept in csn order, is now in head. Please test, syncprov.c revision 1.320. Rein

1 0

Re: (ITS#6744) memory leak when chasing referrals
by arthur＠arthurdejong.org 11 Dec '10

11 Dec '10

--=-dGqU1ahV0Ya5KsADLt/0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2010-12-10 at 19:52 -0800, Howard Chu wrote: > Thanks, reproduced using ldapsearch. Fixed in HEAD. Thanks for the quick response and fix! --=20 -- arthur - arthur(a)arthurdejong.org - http://arthurdejong.org -- --=-dGqU1ahV0Ya5KsADLt/0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAABAgAGBQJNA/gRAAoJECqLdGgQ4K/B3hQP+wbUpmAAws3D7aobKrff+lm1 fe6Bl2kSh/xr7YJptDHQsQf0u7ZfuWPBY7Jm/VYR6vjBqfn2do2J4yZL2yKbkKJS Js9ir23JBgg5hv/qi9c64uA85GTU0NPex7PcWP45y5Y95ZBtDsdGBzvuoePwGCvn Wkb3dNY1Cl6MDL77CZPyoy1qKRHWcWPfVONhbLkQ5LF2BuDPV1dXjFSV1mqRTbLr JXqn1QKYrdRhHhIkZsdXs8RmdtWZ+43lZyqpF2jGtLR3iP8e55kPluih35Mp/fWM 1L/dVYjQO8sV54b1UPGJKAIDHoqacXhRgCZgRTJxQZy3GJ8eKmuM7G4O71TpYuX5 AoxXDcuSOuBY7qDFfTUkICujNDWHXQ0C4/nzN6owyPc5TneXGeJYMgzmyctZb5et jhLwAuS2kwDGNL46XxyuGSF+cDSEeEFxpewo61cXFB/gp2+469MCWfoyWtyp/LHV MZwpTAz9B0FvDjPMOMqd91h4O1WZIxBBo61FnL2iPWD/pNHrmQXlTTQ/y/WMHIXg bWkjqbnT8Qi1PpFYgvo2u+6oe1U4tV6aNRwioQjVyVi8lK+tyC9EL+tJfAGq5f7H JqOZj37PJ5qd26DUU6q2vX7r7RO7wX8TraP0/Kafvg2FnVk+9G+1LSdmjwzviPBp 32EBHtl1GZlq7rP4Q+zm =74Se -----END PGP SIGNATURE----- --=-dGqU1ahV0Ya5KsADLt/0--

1 0

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by hyc＠symas.com 10 Dec '10

10 Dec '10

rmeggins(a)redhat.com wrote: > I "rebased" the patch on top of a recent change: > revision 1.24 > date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 -17 > ITS#6625 Remove some LDAP_R_COMPILEs I didn't quite understand the point of the discussion of SSLv2 clients in the comments on this patch, but committed it anyway. I would hope that nobody is still using SSLv2 these days. Also if a StartTLS request fails, then the rest of the code in tlsm.c should never even be reached; the TLS sockbuf layer wouldn't be installed. > The new patch is here: > ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… > > This patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > > > > -- -- 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#6744) memory leak when chasing referrals
by hyc＠symas.com 10 Dec '10

10 Dec '10

arthur(a)arthurdejong.org wrote: > Full_Name: Arthur de Jong > Version: 2.4.23 > OS: Debian > URL: > Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) > > > There seems to be a memory leak in the LDAP client library when casing > referrals. When the code below is run through valgrind it reports: > > ==30395== 4,184 (80 direct, 4,104 indirect) bytes in 1 blocks are definitely > lost in loss record 3 of 3 > ==30395== at 0x402328F: calloc (vg_replace_malloc.c:467) > ==30395== by 0x41D2CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6) > ==30395== by 0x40650A0: ldap_send_server_request (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x4065EB1: ldap_chase_v3referrals (in > /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x40510A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6) > ==30395== by 0x8048871: main (test.c:28) > > The code below is not very pretty (does not include error handling) but should > free all returned buffers. I can also reproduce the above leak with the > ldapsearch command-line tool. Thanks, reproduced using ldapsearch. Fixed in HEAD. -- -- 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#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 5:16 PM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' >> DESC 'last successful authentication using any method/mech' >> EQUALITY generalizedTimeMatch >> ORDERING generalizedTimeOrderingMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 >> SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) >>=20 >> And we use this attribute in our configuration object to = enable/disable =3D >> (default disabled). >>=20 >> ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' >> DESC 'enable recording of last successful authentication using =3D= >> any method/mech' >> EQUALITY booleanMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 >> SINGLE-VALUE USAGE dsaOperation ) >=20 > Hmm, isn't NAME of the second a little bit confusing since it sounds = like just > the plural of the first? Names should only be for the wire, the wire doesn't get confused. -- Kurt=

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by michael＠stroeder.com 10 Dec '10

10 Dec '10

Kurt(a)OpenLDAP.org wrote: > ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' > DESC 'last successful authentication using any method/mech' > EQUALITY generalizedTimeMatch > ORDERING generalizedTimeOrderingMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 > SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) > > And we use this attribute in our configuration object to enable/disable = > (default disabled). > > ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' > DESC 'enable recording of last successful authentication using = > any method/mech' > EQUALITY booleanMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 > SINGLE-VALUE USAGE dsaOperation ) Hmm, isn't NAME of the second a little bit confusing since it sounds like just the plural of the first? Ciao, Michael.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 12:02 PM, Howard Chu wrote: > Good point. In that case it's probably fine as a separate overlay, the = way it is now. Can we use the schema definition that Isode is using? Not only yes, but hell yes. Reuse and convergence is a good thing. ( 1.3.6.1.4.1.453.16.2.188 NAME 'authTimestamp' DESC 'last successful authentication using any method/mech' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE dsaOperation ) And we use this attribute in our configuration object to enable/disable = (default disabled). ( 1.3.6.1.4.1.453.16.2.189 NAME 'authTimestamps' DESC 'enable recording of last successful authentication using = any method/mech' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE dsaOperation )

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by hyc＠symas.com 10 Dec '10

10 Dec '10

Kurt(a)OpenLDAP.org wrote: > On Dec 10, 2010, at 10:37 AM, jonathan(a)phillipoux.net wrote: > >> On 10/12/10 17:14, Howard Chu wrote: >>> jonathan(a)phillipoux.net wrote: >>>> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>>>> Full_Name: Jonathan Clarke >>>>> Version: RE24 >>>>> OS: >>>>> URL: >>>>> = > ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>>>> Submission from: (NULL) (82.67.204.30) >>>>> =20 >>>>> =20 >>>>> Hi, >>>>> =20 >>>>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, = > that >>>>> intercepts successful binds and records the current timestamp in an >>>>> attribute >>>>> named "bindTimestamp" in the bound-to entry. It's original use-case >>>>> is to detect >>>>> unused accounts. >>>>> =20 >>>>> A configuration parameter (olcLastBindPrecision) allows to set a = > minimum >>>>> precision for the timestamp (ie, don't update the timestamp unless >>>>> it's older >>>>> than<n> seconds). This avoids a performance hit from many >>>>> unnecessary writes in >>>>> case there are many binds per minute/hour/day/week/etc. >>>>> =20 >>>>> Of course, the behaviour this overlay implements is not described = > in >>>>> any RFC, or >>>>> other. However, it closely resembles some of the functionality from >>>>> the password >>>>> policy overlay, and similar functionality already exists in other >>>>> LDAP servers. >>> =20 >>> There is an equivalent attribute defined in the latest ppolicy draft. >>> Perhaps you could use that. > > That attribute is last successful password authentication, not last = > authentication by any means. > > For the latter, I suggest a separate attribute. At Isode, we use an = > authTimestamp dsaOperational attribute for this. > > It's wise to have the updating of this attribute off by default. Good point. In that case it's probably fine as a separate overlay, the way it is now. Can we use the schema definition that Isode is using? -- -- 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#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 10:37 AM, jonathan(a)phillipoux.net wrote: > On 10/12/10 17:14, Howard Chu wrote: >> jonathan(a)phillipoux.net wrote: >>> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>>> Full_Name: Jonathan Clarke >>>> Version: RE24 >>>> OS: >>>> URL: >>>> = ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>>> Submission from: (NULL) (82.67.204.30) >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, = that >>>> intercepts successful binds and records the current timestamp in an >>>> attribute >>>> named "bindTimestamp" in the bound-to entry. It's original use-case >>>> is to detect >>>> unused accounts. >>>>=20 >>>> A configuration parameter (olcLastBindPrecision) allows to set a = minimum >>>> precision for the timestamp (ie, don't update the timestamp unless >>>> it's older >>>> than<n> seconds). This avoids a performance hit from many >>>> unnecessary writes in >>>> case there are many binds per minute/hour/day/week/etc. >>>>=20 >>>> Of course, the behaviour this overlay implements is not described = in >>>> any RFC, or >>>> other. However, it closely resembles some of the functionality from >>>> the password >>>> policy overlay, and similar functionality already exists in other >>>> LDAP servers. >>=20 >> There is an equivalent attribute defined in the latest ppolicy draft. >> Perhaps you could use that. That attribute is last successful password authentication, not last = authentication by any means. For the latter, I suggest a separate attribute. At Isode, we use an = authTimestamp dsaOperational attribute for this. It's wise to have the updating of this attribute off by default. >> Or just submit a patch to incorporate this >> feature into the current ppoloicy overlay. >=20 > Indeed. At the time I wrote this overlay, I think the ppolicy draft = was > not yet finished or at least I wasn't aware of it. My client at the = time > found it useful to just add this simple overlay, without worrying = about > configuring ppolicy. >=20 > Since then, I actually haven't had any time to work on this overlay, = but > today Michael expressed an interest in it, asking for a public IPR > notice, thus the "thread revival". >=20 > I hope to pick it up in the future, and at that point possibly submit = a > patch for ppolicy also, as you suggest. >=20 > Regards, > Jonathan >=20 >=20

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 10 Dec '10

10 Dec '10

On 10/12/10 17:14, Howard Chu wrote: > jonathan(a)phillipoux.net wrote: >> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>> Full_Name: Jonathan Clarke >>> Version: RE24 >>> OS: >>> URL: >>> ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>> Submission from: (NULL) (82.67.204.30) >>> >>> >>> Hi, >>> >>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that >>> intercepts successful binds and records the current timestamp in an >>> attribute >>> named "bindTimestamp" in the bound-to entry. It's original use-case >>> is to detect >>> unused accounts. >>> >>> A configuration parameter (olcLastBindPrecision) allows to set a minimum >>> precision for the timestamp (ie, don't update the timestamp unless >>> it's older >>> than<n> seconds). This avoids a performance hit from many >>> unnecessary writes in >>> case there are many binds per minute/hour/day/week/etc. >>> >>> Of course, the behaviour this overlay implements is not described in >>> any RFC, or >>> other. However, it closely resembles some of the functionality from >>> the password >>> policy overlay, and similar functionality already exists in other >>> LDAP servers. > > There is an equivalent attribute defined in the latest ppolicy draft. > Perhaps you could use that. Or just submit a patch to incorporate this > feature into the current ppoloicy overlay. Indeed. At the time I wrote this overlay, I think the ppolicy draft was not yet finished or at least I wasn't aware of it. My client at the time found it useful to just add this simple overlay, without worrying about configuring ppolicy. Since then, I actually haven't had any time to work on this overlay, but today Michael expressed an interest in it, asking for a public IPR notice, thus the "thread revival". I hope to pick it up in the future, and at that point possibly submit a patch for ppolicy also, as you suggest. Regards, Jonathan

1 0

Oddities with searching for a specific attribute value
by Sebastian Urbanneck 10 Dec '10

10 Dec '10

Sorry for this weird topic, but I didn'T know how to name this one. These are the facts: we're using the phamm.schema from the PHAMM Project for saving virtual domain entries in our Ldap database. Searching for them is mostly no pronblem, but one specific circumstance is bothering me to death: when I try to search for a specific value of the attribute "vd", the corresponding entry is not always found. Any other attribute does the trick, but vd does'nt. For example: the search for (using the root_dn) ldapsearch -x -W -D "cn=admin,dc=uebergebuehr,dc=de" -b "ou=domains,dc=uebergebuehr,dc=de" "(vd=*) -s"one" produces following output: ---------output------------- # extended LDIF # # LDAPv3 # base <vd=lak-hessen.de,ou=domains,dc=uebergebuehr,dc=de> with scope baseObject # filter: (vd=*) # requesting: ALL # # lak-hessen.de, domains, uebergebuehr.de dn: vd=lak-hessen.de,ou=domains,dc=uebergebuehr,dc=de vd: lak-hessen.de lastChange: 1291723263 maxMail: 100 maxAlias: 100 maxQuota: 100 accountActive: TRUE editAV: TRUE delete: FALSE postfixTransport: dovecot objectClass: top objectClass: VirtualDomain description: lak-hessen.de # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------- This is true for everytime I put a Wildcard (*) into the search pattern, and with scope "sub" there's also no matter in which part of the tree above this entry I am. But when I'm searching specificly for the value (lak-hessen.de) nothin is found, no matter in which entry I am and which scope use. Strangely this pattern _is_ found when you go into the entry of the domain itself (vd=lak-hessen.de,ou=domains,...) and search with scobe 'base'. Any idea what I'm doing wrong? Or is this a bug? I think ACLs are ruled out because of using the root_dn. I didn't want to file a Bug before being reallly sure that this is one regards Sebastian

2 1

Re: (ITS#6742) Patch - Mozilla NSS - centralize and improve certificate verification
by rmeggins＠redhat.com 10 Dec '10

10 Dec '10

New patch to supplement the other patch for this ITS: ftp://ftp.openldap.org/incoming/openldap-2.4.23-allow-self-issued-certs-to-… Should only allow a cert to pass verification with BasicConstraints CA == FALSE if the cert is self issued. This is what openssl does. Forgot to include the IP statement for the previous patch. The statement applies to that patch and this one. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by hyc＠symas.com 10 Dec '10

10 Dec '10

jonathan(a)phillipoux.net wrote: > On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: >> URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >> Submission from: (NULL) (82.67.204.30) >> >> >> Hi, >> >> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that >> intercepts successful binds and records the current timestamp in an attribute >> named "bindTimestamp" in the bound-to entry. It's original use-case is to detect >> unused accounts. >> >> A configuration parameter (olcLastBindPrecision) allows to set a minimum >> precision for the timestamp (ie, don't update the timestamp unless it's older >> than<n> seconds). This avoids a performance hit from many unnecessary writes in >> case there are many binds per minute/hour/day/week/etc. >> >> Of course, the behaviour this overlay implements is not described in any RFC, or >> other. However, it closely resembles some of the functionality from the password >> policy overlay, and similar functionality already exists in other LDAP servers. There is an equivalent attribute defined in the latest ppolicy draft. Perhaps you could use that. Or just submit a patch to incorporate this feature into the current ppoloicy overlay. >> >> I post it here in the hope that it may serve others, and in case the OpenLDAP >> wishes to include it in one form or another. I would most appreciate any >> comments or feedback. -- -- 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#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by hyc＠symas.com 10 Dec '10

10 Dec '10

cmikk(a)qwest.net wrote: > This fix would have the effect of treating the sessionlog > as empty until it overflows, and will cause unnecessary > refresh traffic. > > Other than the patch I suggested (using the list head's > CSN value directly), I can think of two other approaches: > > 1) When adding an entry to the sessionlog, check > if sl_mincsn is empty. If it is, update sl_mincsn > to the new entry's CSN. > > 2) When initializing the sessionlog, set sl_mincsn > to the maximum contextCSN value of the underlying > database. > > #2 seems ideal from an efficiency standpoint, although it > differs from the algorithm the current code appears to be > intended to implement. #2 sounds fine, but it sounds like Rein has already got a good solution underway. -- -- 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#6744) memory leak when chasing referrals
by arthur＠arthurdejong.org 10 Dec '10

10 Dec '10

Full_Name: Arthur de Jong Version: 2.4.23 OS: Debian URL: Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) There seems to be a memory leak in the LDAP client library when casing referrals. When the code below is run through valgrind it reports: ==30395== 4,184 (80 direct, 4,104 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3 ==30395== at 0x402328F: calloc (vg_replace_malloc.c:467) ==30395== by 0x41D2CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6) ==30395== by 0x40650A0: ldap_send_server_request (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x4065EB1: ldap_chase_v3referrals (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x40510A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x8048871: main (test.c:28) The code below is not very pretty (does not include error handling) but should free all returned buffers. I can also reproduce the above leak with the ldapsearch command-line tool. Some background: http://www.openldap.org/lists/openldap-technical/201012/msg00031.html http://lists.arthurdejong.org/nss-pam-ldapd-users/2010/msg00166.html -----8<-- test.c --8<----- #include <stdio.h> #include <errno.h> #define LDAP_DEPRECATED 1 #include <ldap.h> int main(int argc,char *argv[]) { char *base="dc=test,dc=tld"; char *filter="(objectClass=posixAccount)"; char *attrs[] = { "uid", NULL }; int i; LDAP *ld; LDAPMessage *msg=NULL; int msgid; char **values; /* set up connection */ ldap_initialize(&ld,"ldap://localhost";); i=3; ldap_set_option(ld,LDAP_OPT_PROTOCOL_VERSION,&i); ldap_simple_bind_s(ld,NULL,NULL); /* start search and handle results */ ldap_search_ext(ld,base,LDAP_SCOPE_SUB,filter,attrs, 0,NULL,NULL,NULL,LDAP_NO_LIMIT,&msgid); while (1) { switch (ldap_result(ld,msgid,LDAP_MSG_ONE,NULL,&msg)) { case LDAP_RES_SEARCH_ENTRY: /* we have a normal search entry, print some attribute values */ values=ldap_get_values(ld,msg,attrs[0]); for (i=0;values[i]!=NULL;i++) fprintf(stderr,"%s=%s\n",attrs[0],values[i]); ldap_value_free(values); break; case LDAP_RES_SEARCH_RESULT: /* end of results */ ldap_msgfree(msg); ldap_unbind(ld); return 0; case LDAP_RES_SEARCH_REFERENCE: break; /* just ignore search references */ default: /* we have some error condition, bail out */ return -1; } ldap_msgfree(msg); } } -----8<-- test.c --8<-----

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 10 Dec '10

10 Dec '10

On 10/12/10 14:53, Kurt Zeilenga wrote: > > On Dec 10, 2010, at 6:43 AM, jonathan(a)phillipoux.net wrote: > >> I'd like to add an IPR notice to this >> contribution: > > I note that you only provide half the notice. A complete notice would be followed by a statement of what license the contribution is provided under. Ah, the licence is included in the files, but I repeat it here for clarity: * Copyright 2009 Jonathan Clarke <jonathan(a)phillipoux.net>. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted only as authorized by the OpenLDAP * Public License. * * A copy of this license is available in the file LICENSE in the * top-level directory of the distribution or, alternatively, at * <http://www.OpenLDAP.org/license.html>. Jonathan

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 6:43 AM, jonathan(a)phillipoux.net wrote: > I'd like to add an IPR notice to this > contribution: I note that you only provide half the notice. A complete notice would = be followed by a statement of what license the contribution is provided = under. -- Kurt=

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 10 Dec '10

10 Dec '10

On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz > Submission from: (NULL) (82.67.204.30) > > > Hi, > > Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that > intercepts successful binds and records the current timestamp in an attribute > named "bindTimestamp" in the bound-to entry. It's original use-case is to detect > unused accounts. > > A configuration parameter (olcLastBindPrecision) allows to set a minimum > precision for the timestamp (ie, don't update the timestamp unless it's older > than <n> seconds). This avoids a performance hit from many unnecessary writes in > case there are many binds per minute/hour/day/week/etc. > > Of course, the behaviour this overlay implements is not described in any RFC, or > other. However, it closely resembles some of the functionality from the password > policy overlay, and similar functionality already exists in other LDAP servers. > > I post it here in the hope that it may serve others, and in case the OpenLDAP > wishes to include it in one form or another. I would most appreciate any > comments or feedback. > > Regards, > Jonathan > > PS: please note that the OIDs used are not registered, but used temporarily. I > do not currently have access to a registered OID to use. To respond to an off-list request, I'd like to add an IPR notice to this contribution: The above mentioned files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the files were developed by Jonathan Clarke <jonathan(a)phillipoux.net>. I have not assigned rights and/or interest in this work to any party. Hope this is the right wording... Jonathan

1 0

Re: (ITS#6743) LDAP 3000
by masarati＠aero.polimi.it 10 Dec '10

10 Dec '10

sylvie.longeau(a)axa-lm.com wrote: > Full_Name: Longeau > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.18.2.133) > > > Please, could you explain what is the [LDAP 3000] error code? This is not an OpenLDAP (nor an LDAP) error code, as far as I know. In any case, the ITS is intended to track software bugs and related issues. Usage questions should be addressed to openldap-technical. This ITS will be closed. p.

1 0

(ITS#6743) LDAP 3000
by sylvie.longeau＠axa-lm.com 10 Dec '10

10 Dec '10

Full_Name: Longeau Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.18.2.133) Please, could you explain what is the [LDAP 3000] error code? Thanks

1 0

(ITS#6742) Patch - Mozilla NSS - centralize and improve certificate verification
by rmeggins＠redhat.com 09 Dec '10

09 Dec '10

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-centralize-and-improve-cert… Submission from: (NULL) (76.113.111.209) The changes are to make Mozilla NSS certificate verification work like OpenSSL. The former is using Fedora 14 with Mozilla NSS 3.12.8, the latter, Fedora 13 with OpenLDAP 2.4.21 and OpenSSL 1.0.0b. I tested the following scenarios: * self signed server + CA cert as generated by openssl req -x509 * server cert generated by self signed CA (/etc/pki/tls/misc/CA) I tested various combinations of certs, with and with CA certs, on both the server and the client, and verified that the F-14 system worked the same as the F-13, excepting differences in error messages. I added a new function - tlsm_verify_cert() - that could handle different types of cert verification. I replaced other calls to CERT_Verify* with this function and consolidated exception and error handling there. In order to make error handling more flexible, I use the CERT_VerifyCertificate() function which takes a logging parameter. The log contains a list of the errors found along with each cert that caused a problem (a cert may be listed in the log multiple times if a cert had more than one problem). The use of logging also allows cert verification to continue to search for all problems, rather than just returning at the first problem. This allows fine grained error handling which is needed for the following problem: OpenSSL allows CA certs with the Basic Constraints extension set with the CA flag set to FALSE. NSS does not. If tlsm_verify_cert finds this case, it can just log a warning and allow it. I also added the ability to specify an error code to ignore in cert verification, which is needed when using a self signed CA cert for the server cert. I also changed the way trust is handled. In OpenSSL, certs specified by the user (e.g. in TLS_CACERT, TLS_CACERTDIR, TLS_CERT) are explicitly trusted. So, for example, you can specify a server or client cert without specifying the CA cert issuer, and OpenSSL will allow it. NSS will allow it if the cert is specified as trusted. I changed the add_cert code to accept an istrusted flag so that you can specify if a PEM cert is trusted. The PEM NSS code stores trusted certs in a special slot, so the code had to be changed to accommodate that. Finally, I added a default error message which has the error code if an error message was not already set by the library.

1 0

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by rmeggins＠redhat.com 09 Dec '10

09 Dec '10

I "rebased" the patch on top of a recent change: revision 1.24 date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 -17 ITS#6625 Remove some LDAP_R_COMPILEs The new patch is here: ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by masarati＠aero.polimi.it 09 Dec '10

09 Dec '10

rein(a)OpenLDAP.org wrote: > On 09.12.10 09.09, masarati(a)aero.polimi.it wrote: >> I think the best (blind) fix consists in only performing that test if >> sl_mincsn is assigned a value; something like > > I'm looking at an extended fix. The problem with the current > implementation is that is assumes the entries arrives in CSN order, > which isn't necessarily true in a MMR configuration. > > My fix drops sl_mincsn, keeps the log queue in CSN order and compares > with the head entry. It also wipes the log if it receives any changes > without CSN (i.e during refresh). > > There might still be a theoretical problem there, if the sid of an entry > in the log is not in the set sent by the consumer. But since we know > they have the same number of CSNs this can only happen during initial > setup of a multi-master configuration. In which case the admins real > problem is that he didn't bring the servers online in a controlled order.. OK, I'm not looking at this any more. Thanks, p.

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 09 Dec '10

09 Dec '10

On 09.12.10 09.09, masarati(a)aero.polimi.it wrote: > I think the best (blind) fix consists in only performing that test if > sl_mincsn is assigned a value; something like I'm looking at an extended fix. The problem with the current implementation is that is assumes the entries arrives in CSN order, which isn't necessarily true in a MMR configuration. My fix drops sl_mincsn, keeps the log queue in CSN order and compares with the head entry. It also wipes the log if it receives any changes without CSN (i.e during refresh). There might still be a theoretical problem there, if the sid of an entry in the log is not in the set sent by the consumer. But since we know they have the same number of CSNs this can only happen during initial setup of a multi-master configuration. In which case the admins real problem is that he didn't bring the servers online in a controlled order.. Rein

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by cmikk＠qwest.net 09 Dec '10

09 Dec '10

On Thu, Dec 09, 2010 at 09:09:21AM +0100, Pierangelo Masarati wrote: > I think the best (blind) fix consists in only performing that test > if sl_mincsn is assigned a value; something like > > /* Are there any log entries, and is the consumer state > * present in the session log? > */ > - if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, > &sl->sl_mincsn ) >= 0 ) { > + if ( !BER_BVISEMPTY( &sl->sl_mincsn ) && > + sl->sl_num > 0 && > + ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) > + { > do_present = 0; > /* mutex is unlocked in playlog */ > syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids ); > > However I'd like to hear some other opinion. This fix would have the effect of treating the sessionlog as empty until it overflows, and will cause unnecessary refresh traffic. Other than the patch I suggested (using the list head's CSN value directly), I can think of two other approaches: 1) When adding an entry to the sessionlog, check if sl_mincsn is empty. If it is, update sl_mincsn to the new entry's CSN. 2) When initializing the sessionlog, set sl_mincsn to the maximum contextCSN value of the underlying database. #2 seems ideal from an efficiency standpoint, although it differs from the algorithm the current code appears to be intended to implement. -- Chris Mikkelson | Vampireware; n, a project capable of sucking the cmikk(a)qwest.net | lifeblood out of anyone unfortunate enough to be | assigned to it which never actually sees the light | of day, but nonetheless refuses to die. (tlode(a)nyx.net)

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by masarati＠aero.polimi.it 09 Dec '10

09 Dec '10

I think the best (blind) fix consists in only performing that test if sl_mincsn is assigned a value; something like /* Are there any log entries, and is the consumer state * present in the session log? */ - if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) { + if ( !BER_BVISEMPTY( &sl->sl_mincsn ) && + sl->sl_num > 0 && + ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) + { do_present = 0; /* mutex is unlocked in playlog */ syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids ); However I'd like to hear some other opinion. p.

1 0

(ITS#6741) x500UniqueIdentifier handling
by jgcardoso＠seguridata.com 08 Dec '10

08 Dec '10

Full_Name: Juan González Cardoso Version: 2.4.23 OS: Red Hat 5.5 EL URL: ftp://ftp.openldap.org/incoming/juan-gonzalez-101208.cer Submission from: (NULL) (201.148.141.170) Inserting userCertificate values containing x500UniqueIdentifier attribute at issuerNames fails. Some values even makes server to crash.

1 0

Re: (ITS#6740) syncrepl/--disable-rewrite dependency
by masarati＠aero.polimi.it 08 Dec '10

08 Dec '10

> What's special about DN rewriting so it has a configure option > anyway? It doesn't disable building of libraries/librewrite. It used to, as far as I remember. I remember something about performing simple suffixmassage when librewrite is not built. In any case I agree that given the widespread usage of rewrite capabilities (authz regexp, for example) not building librewrite is somehow pointless. p.

1 0

Re: (ITS#6740) syncrepl/--disable-rewrite dependency
by h.b.furuseth＠usit.uio.no 08 Dec '10

08 Dec '10

What's special about DN rewriting so it has a configure option anyway? It doesn't disable building of libraries/librewrite. -- Hallvard

1 0

(ITS#6740) syncrepl/--disable-rewrite dependency
by h.b.furuseth＠usit.uio.no 08 Dec '10

08 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard configure should mention syncrepl here: --enable-rewrite enable DN rewriting in back-ldap and rwm overlay test059-slave-config fails with --disable-rewrite. Testrun/test.out says parse_syncrepl_line: unable to parse "suffixmassage=cn=schema,cn=config,cn=slave"

1 0

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 06 Dec '10

06 Dec '10

On 12/ 6/10 04:09 AM, h.b.furuseth(a)usit.uio.no wrote: > I've made two fixes (I hope) to the concurrency commit, please review: > > - In do_abandon(), protected ldap_free_connection() with > ld->ld_conn_mutex. The function would unlock it when it did not own > the mutex. > > However I do not know why the mutex was moved out of > ldap_free_connection(), so maybe something more needs to be done. > The abandon operation is now protected by it's own abandon mutex, not by the conn mutex. So do_abandon is not protecting the conn unless it is actually in use. ldap_free_connection reference counts the connection and only frees it if there are no other users of the connection. This is why ldap_free_connection requires protection. If there are multiple simultaneous threads using the connection some of which may have in flight operations, those threads are not interrupted by the abandon of another thread. Consider connection A with 3 threads performing searches. Thread 3 may abandon it's search but threads 1 and 2 may continue with their operations. Removing the protection around ldap_free_connection will disrupt the reference counting for the connection and cause potential connection leakage and/or disrupt other threads usage of the connection. Doug.

1 0

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

I've made two fixes (I hope) to the concurrency commit, please review: - I inverted the test in NT threads MUTEX_FIRSTCREATE. I assume LDO_MUTEX_NULL = (HANDLE)0 is not a valid handle, so FIRSTCREATE must initialize m if it *is* 0, not if is *not*. - In do_abandon(), protected ldap_free_connection() with ld->ld_conn_mutex. The function would unlock it when it did not own the mutex. However I do not know why the mutex was moved out of ldap_free_connection(), so maybe something more needs to be done. Also I've cleaned up macros and namespace: Add proper values for NO_THREADS. Support LDAP_THREAD_DEBUG. Define LDAP_INT_* and LDAP_DEBUG_* in ldap_int_thread.h, LDAP_PVT_* in ldap_pvt_thread.h. libraries/libldap/ldap-int.h: Remove unnecessary #ifdef LDAP_R_COMPILE for LDAP_NEXT_MSGID. define LDAP_LDO_MUTEX_NULLARG as ,LDAP_PVT_MUTEX_NULL or empty in the same place which decides whether the initializer is needed. Wrap some macros and arguments in parens or do{}while(0), so they can be used more like C statements. Also replace empty macros with ((void) 0) expansions, to shut up 'empty statement' compiler warnings. Finally, I've another wish for the test060-mt-hot: This test takes way to long under Valgrind. It ought to obey $TESTLOOPS (default 50) like the concurrency tests do: Set parameters to run ca $TESTLOOPS/50 of the current time. I don't know which parameters it's best to reduce in that case, however? -- Hallvard

1 0

Re: (ITS#6737) slapmodify strangeness
by masarati＠aero.polimi.it 06 Dec '10

06 Dec '10

> >> slapdmodify(8) is the (nearly untested) result of non negligible >> cut'n'paste. > > In any case, there seems to be significant side code commonality between > slapadd and slapmodify, basically everything related to syncing the > context entry. Maybe we should move that code in helpers in slapcommon.c. See <ftp://ftp.openldap.org/incoming/pierangelo.masarati-2010-12-06-update_ctxcs…>. p.

1 0

Re: (ITS#6737) slapmodify strangeness
by masarati＠aero.polimi.it 06 Dec '10

06 Dec '10

> slapdmodify(8) is the (nearly untested) result of non negligible > cut'n'paste. In any case, there seems to be significant side code commonality between slapadd and slapmodify, basically everything related to syncing the context entry. Maybe we should move that code in helpers in slapcommon.c. p.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

hyc(a)symas.com writes: > See the definition of pwdChangedTime, section 5.3.2: Duh, I misread what you said. In any case, it's a separate issue. That's about slapd expiring the passwor, this patch is about the user deleting it. -- Hallvard

1 0

(ITS#6739) broken do_syncrep2()
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd/syncrepl.c:do_syncrep2() initializes many variables once which should have been initialized inside the loop. I'll add the initializations I can figure out, and move most variables into the loop for readability. TODO: Variables 'm' and 'refreshDeletes' may still be wrong. In particular 'm'. It "feels" like it should be local to the loop, but there's no logic that I can see to prevent previous value from being used. Perhaps they depend on the peer not breaking the sync protocol? I haven't read that myself, I'm just peering at the code. I've added three somewhat arbitrary bits of code for error handling: - A Debug() statement on line 847 which can likely be improved. - Set err and rc to LDAP_OTHER on ldap_parse_result/ldap_get_option failure. The correct fix would be proper error checks (ITS#6738), but I don't know what to do on error.

1 0

Re: (ITS#6737) slapmodify strangeness
by masarati＠aero.polimi.it 06 Dec '10

06 Dec '10

> Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > 'sid' in slapmodify.c is read uninitialized before it is written, at line > 693: > > if ( rc == EXIT_SUCCESS && update_ctxcsn && !dryrun && sid != > SLAP_SYNC_SID_MAX > + 1 ) { > > A loop _below_ that statement can set sid to the expected value: > > for ( sid = 0; sid <= SLAP_SYNC_SID_MAX; sid++ ) > > Also slapmodify sets up but does not use variables opbuf and op. slapdmodify(8) is the (nearly untested) result of non negligible cut'n'paste. p.

1 0

(ITS#6738) missing checks for ber errors
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard There are a fair number of ber calls which do not check for errors: Just ber_scanf and use the expected output variable, which may or may not have a useful NULL value on error. Syncrepl is particularly bad. This in slapd/ and libldap/: egrep '^<tab>*ber_(scanf|get_)' *.c */*.c returns mostly syncrepl matches. I can't even fix these easily because there's not enough error handling code to copy. grepping for ber_(printf|put_) find other modules as well.

1 0

(ITS#6737) slapmodify strangeness
by h.b.furuseth＠usit.uio.no 05 Dec '10

05 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard 'sid' in slapmodify.c is read uninitialized before it is written, at line 693: if ( rc == EXIT_SUCCESS && update_ctxcsn && !dryrun && sid != SLAP_SYNC_SID_MAX + 1 ) { A loop _below_ that statement can set sid to the expected value: for ( sid = 0; sid <= SLAP_SYNC_SID_MAX; sid++ ) Also slapmodify sets up but does not use variables opbuf and op.

1 0

(ITS#6736) Listener info destroyed too early on shutdown
by h.b.furuseth＠usit.uio.no 05 Dec '10

05 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard On shutdown, slapd_daemon_task() calls close_listeners() which destroys slap_listeners[] while other threads may be accessing it. This is not mutex-protected. Valgrind reports freed data accesses in back-monitor and slapd_listener() when they try to read the URLs in the listeners. Giving HEAD a minimal fix: Stop listening but delay destruction. If anyone feels like it, the new 'listening' flag probably can be used more intelligently, e.g. by rearranging the use of it and some shutdown flags.

1 0

(ITS#6735) Uninitialized filter in slapd-tester
by h.b.furuseth＠usit.uio.no 04 Dec '10

04 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard rflts[jj] can be used uninitialized at slapd-tester.c:875. Fixing.

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 04 Dec '10

04 Dec '10

masarati(a)aero.polimi.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Hopefully fixed with the latest ITS#6632/6720 commits. > > You mean ITS#6727, I guess. I fixed ITS#6720 (rwm.c 1.132 -> 1.133), > it looked unrelated. For me, ITS#6727 is now fixed with your patch. > Can you confirm, Michael? 30 test iterations without problems. Seems to be fixed now. Ciao, Michael.

1 0

(ITS#6734) Implment delta-sync based MMR
by quanah＠OpenLDAP.org 03 Dec '10

03 Dec '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) To help resolve ITS#6097, it would be helpful to have delta-sync MMR available. I'm mainly filing this bug for tracking.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by hyc＠symas.com 03 Dec '10

03 Dec '10

Hallvard B Furuseth wrote: > Howard Chu writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. >>> >>> Reproducing the bug: >>> >>> userPassword can exist without pwdChangedTime if you bypass >>> ppolicy: Use slapadd to add an entry with userPassword, or add >>> it to a subtree with no policy and then configure a policy. >>> >>> Then set up ppolicy and use ldapmodify to delete userPassword. >> >> In that case the correct fix is to skip the pwdChangedTime attribute >> completely. > > Well, that's what this fix does in this particular code chunk: > Don't try to delete pwdChangedTime if it isn't there. > >> The ppolicy spec says that entries without pwdChangedTime are not >> subject to password expiration at all. > > Sounds like a different issue, but I don't see where it says that. > What I did find is > > 8.2.7. Policy State Updates > > If the value of either pwdMaxAge or pwdMinAge is non-zero, the server > updates the pwdChangedTime attribute on the entry to the current > time. > See the definition of pwdChangedTime, section 5.3.2: 5.3.2. pwdChangedTime This attribute specifies the last time the entry's password was changed. This is used by the password expiration policy. If this attribute does not exist, the password will never expire. -- -- 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

MemberOf out of sync on consumer[s]
by Yuri Bank 03 Dec '10

03 Dec '10

Hello, I've been putting this off for a while, but this is happening frequently enough that I think its time to ask for opinions on the bug I'm running into with OpenLDAP and the MemberOf overlay. Version: 2.4.23 Configuration: Single Provider, with 4 Consumers. It seems that when I add a new users on my provider, the MemberOf attribute disappears randomly for some users, on some ( not all ) consumer nodes. Everything in the DIT is in tact, and the changes made on my provider are replicated to the consumers correctly. The only issue here is with the memberof attribute. The only way for me to remedy this problem is to shutdown slapd on the affected consumer node, delete everything in /var/sun/slapd, and then start slapd again which then fully syncs with my provider with all memberof attributes in tact. My testing shows that this is triggered by making changes to to my LDAP groups/users on the provider node, but that is all I can find. Nothing in the logs gives me any clues as to what is happening. Has anyone experienced similar problems? Thanks, -Yuri Bank

2 1

Re: (ITS#6684) Patch for autogroup overlay
by ryans＠aweber.com 03 Dec '10

03 Dec '10

Just wanted to say that I've tested the patch Norbert submitted with 2.4.21 and 2.4.23, and it fixes the problems for me on both installations. Great job on the patch, Norbert. -Ryan

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by masarati＠aero.polimi.it 03 Dec '10

03 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Hopefully fixed with the latest ITS#6632/6720 commits. You mean ITS#6727, I guess. I fixed ITS#6720 (rwm.c 1.132 -> 1.133), it looked unrelated. For me, ITS#6727 is now fixed with your patch. Can you confirm, Michael? Thanks, p.

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Hopefully fixed with the latest ITS#6632/6720 commits. -- Hallvard

1 0

(ITS#6733) LDAP_MEMORY_DEBUG issues
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard With LDAP_MEMORY_DEBUG, - ber_memcalloc_x does not check for overflow. - LBER_MEM_JUNK and the ber_int_mem_hdr initializer get compiler warnings. Fixing.

1 0

Re: (ITS#6632) Core dump in test030 when using back-ldap
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Easily found with valgrind --track-origins=yes. Fixed in rwm.c rev 1.134. -- Hallvard

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs