openldap-bugs December 2008

openldap-bugs@openldap.org

36 participants
131 discussions

Re: (ITS#5854) Double send response in meta backend
by ando＠sys-net.it 11 Dec '08

11 Dec '08

hyc(a)symas.com wrote: > Thanks for your report. Sounds a lot like ITS#4782... Howard, the proposed fix is fine, but I think the issue is better addressed in back-ldap by means of the ldap_back_send_t mask without the need of an additional argument. I'm testing a different fix. p. > On Thu, Dec 11, 2008 at 10:14:23AM +0000, jorge.perez(a)adaptia.net wrote: >> Full_Name: Jorge Perez Burgos >> Version: 2.4.11 >> OS: SLES 10 >> URL: ftp://ftp.openldap.org/incoming/back-meta_changes.diff.gz >> Submission from: (NULL) (194.237.142.20) >> >> >> Meta backend send two response codes when trying to reconnect to other slapd. >> >> Steps to reproduce: >> Configure two slapds, slapd_A and slapd_B. slapd_A connects to slapd_B trough >> meta backend. Do some traffic operations. Restart slapd_B and do some modify, >> delete or add operation, response code 52 is received although the operation is >> sucessful. Using a tcpdump you can see two response codes for the request. >> >> I attach a possible patch for this issue. >> >> > > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5854) Double send response in meta backend
by hyc＠symas.com 11 Dec '08

11 Dec '08

Thanks for your report. Sounds a lot like ITS#4782... On Thu, Dec 11, 2008 at 10:14:23AM +0000, jorge.perez(a)adaptia.net wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.11 > OS: SLES 10 > URL: ftp://ftp.openldap.org/incoming/back-meta_changes.diff.gz > Submission from: (NULL) (194.237.142.20) > > > Meta backend send two response codes when trying to reconnect to other slapd. > > Steps to reproduce: > Configure two slapds, slapd_A and slapd_B. slapd_A connects to slapd_B trough > meta backend. Do some traffic operations. Restart slapd_B and do some modify, > delete or add operation, response code 52 is received although the operation is > sucessful. Using a tcpdump you can see two response codes for the request. > > I attach a possible patch for this issue. > >

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 11 Dec '08

11 Dec '08

--=-3TUJtt6yg+CvD9VzraMk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-12-11 at 23:22 +0100, Pierangelo Masarati wrote: > Andrew Bartlett wrote: > > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > >> A tentative implementation is in HEAD, please test. You need to: > >=20 > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > > the Samba4 side of the implementation took far longer than I expected). > >=20 > >> - configure as --enable-deref > >> > >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > >> work as global overlay yet, sorry). > >=20 > > This is something Samba4 will need, as many of our links are > > cross-database. But fixing this for a single DB is a big help in any > > case. >=20 > Apparently this was fixed during the overlay's shakedown, as it seems to=20 > work as expected when only instantiated as global. In fact, nothing was=20 > preventing it from working this way by design, it only didn't work at=20 > some point of its evolution. Please test. Indeed, it works well as a global. Thanks! My only issue remaining is the clarification over the ASN.1 encoding of the control. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-3TUJtt6yg+CvD9VzraMk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQdk5z4A8Wyi0NrsRAiiOAKCUywnlFS2RIZlclADU/woC7id7OwCfbfwD fh4vPeyWTWqBYACEYVFgdZA= =UdNB -----END PGP SIGNATURE----- --=-3TUJtt6yg+CvD9VzraMk--

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 11 Dec '08

11 Dec '08

--=-WGywWWDfCXc78PSX7dDA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-12-11 at 23:17 +0100, Pierangelo Masarati wrote: > Andrew Bartlett wrote: > > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > >> A tentative implementation is in HEAD, please test. You need to: > >=20 > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > > the Samba4 side of the implementation took far longer than I expected). > >=20 > >> - configure as --enable-deref > >> > >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > >> work as global overlay yet, sorry). > >=20 > > This is something Samba4 will need, as many of our links are > > cross-database. But fixing this for a single DB is a big help in any > > case. > >=20 > >> - run searches like > >> > >> $ ldapsearch -x -b dc=3Dexample,dc=3Dcom -E 'deref=3Dmember:entryUUID' > >> > >> you'll see results like > >=20 > > When using Samba4's client, it seems to work, but it is as if it extend= s > > the control to the full expected length, but not the data. Ie, attache= d > > this is the control response I got back from the 'make testenv' > > environment in Samba4. I've also attached the full LDAP request. > >=20 > > The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 > > parsing bug). >=20 > I've found the bug (erroneous manipulation of octet strings containing=20 > '\0' octets). The objectSid is octet string-valued. Should be fixed=20 > now; please test. While I'm mostly at sea on ASN.1, I don't think the OpenLDAP's implementation matches your IETF draft (if not, an education on subtle details of ASN.1 will be appreciated) draft-masarati-ldap-deref-00 > 2.3. Control Response >=20 >=20 > The control type is deref-oid (IANA assigned; see Section 6). The > specification of the Dereference Control response is: >=20 > controlValue ::=3D SEQUENCE OF derefRes DerefRes >=20 > DerefRes ::=3D SEQUENCE { > derefAttr AttributeDescription, > derefVal LDAPDN, > attrVals [0] PartialAttributeList OPTIONAL } >=20 > PartialAttributeList ::=3D SEQUENCE OF > partialAttribute PartialAttribute >=20 > PartialAttribute is defined in [RFC4511]; the definition is reported > here for clarity: >=20 > PartialAttribute ::=3D SEQUENCE { > type AttributeDescription, > vals SET OF value AttributeValue } >=20 the output of dumpasn1 on the control: > 0 983: SEQUENCE { > 4 168: SEQUENCE { > 7 8: OCTET STRING 'memberOf' > 17 56: OCTET STRING > : 'cn=3DEnterprise Admins,cn=3DUsers,dc=3Dsamba,dc=3Dexamp= l' > : 'e,dc=3Dcom' > 75 98: [0] { > 77 51: SEQUENCE { Shouldn't there be another SEQUENCE { here? > 79 9: OCTET STRING 'entryUUID' > 90 38: SET { > 92 36: OCTET STRING > '24476f18-5c24-102d-9945-7320c1040f54' > : } > : } > 130 43: SEQUENCE { > 132 9: OCTET STRING 'objectSid' > 143 30: SET { > 145 28: OCTET STRING > : 01 05 00 00 00 00 00 05 15 00 00 00 AB BE DB 7B > : 16 72 AE E6 53 BE 65 6F 07 02 00 00 > : } > : } > : } > : } >=20 Thanks, Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-WGywWWDfCXc78PSX7dDA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQa1Nz4A8Wyi0NrsRAtyAAJ9Dqzqn3DknKqThzy7KML5Z+i/h2wCfZ2nM d8HdE9UXPLaN2DZRwIseCk0= =HFZS -----END PGP SIGNATURE----- --=-WGywWWDfCXc78PSX7dDA--

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 11 Dec '08

11 Dec '08

Andrew Bartlett wrote: > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: >> A tentative implementation is in HEAD, please test. You need to: > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > the Samba4 side of the implementation took far longer than I expected). > >> - configure as --enable-deref >> >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't >> work as global overlay yet, sorry). > > This is something Samba4 will need, as many of our links are > cross-database. But fixing this for a single DB is a big help in any > case. Apparently this was fixed during the overlay's shakedown, as it seems to work as expected when only instantiated as global. In fact, nothing was preventing it from working this way by design, it only didn't work at some point of its evolution. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 11 Dec '08

11 Dec '08

Andrew Bartlett wrote: > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: >> A tentative implementation is in HEAD, please test. You need to: > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > the Samba4 side of the implementation took far longer than I expected). > >> - configure as --enable-deref >> >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't >> work as global overlay yet, sorry). > > This is something Samba4 will need, as many of our links are > cross-database. But fixing this for a single DB is a big help in any > case. > >> - run searches like >> >> $ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID' >> >> you'll see results like > > When using Samba4's client, it seems to work, but it is as if it extends > the control to the full expected length, but not the data. Ie, attached > this is the control response I got back from the 'make testenv' > environment in Samba4. I've also attached the full LDAP request. > > The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 > parsing bug). I've found the bug (erroneous manipulation of octet strings containing '\0' octets). The objectSid is octet string-valued. Should be fixed now; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5854) Double send response in meta backend
by jorge.perez＠adaptia.net 11 Dec '08

11 Dec '08

Full_Name: Jorge Perez Burgos Version: 2.4.11 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/back-meta_changes.diff.gz Submission from: (NULL) (194.237.142.20) Meta backend send two response codes when trying to reconnect to other slapd. Steps to reproduce: Configure two slapds, slapd_A and slapd_B. slapd_A connects to slapd_B trough meta backend. Do some traffic operations. Restart slapd_B and do some modify, delete or add operation, response code 52 is received although the operation is sucessful. Using a tcpdump you can see two response codes for the request. I attach a possible patch for this issue.

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 10 Dec '08

10 Dec '08

--=-svDYOuAyXlEqIDWU48Ko Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-12-11 at 12:22 +1100, Andrew Bartlett wrote: > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > > A tentative implementation is in HEAD, please test. You need to: >=20 > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > the Samba4 side of the implementation took far longer than I expected). >=20 > > - configure as --enable-deref > >=20 > > - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > > work as global overlay yet, sorry). >=20 > This is something Samba4 will need, as many of our links are > cross-database. But fixing this for a single DB is a big help in any > case. >=20 > > - run searches like > > > > $ ldapsearch -x -b dc=3Dexample,dc=3Dcom -E 'deref=3Dmember:entryUUID' > >=20 > > you'll see results like >=20 > When using Samba4's client, it seems to work, but it is as if it extends > the control to the full expected length, but not the data. Ie, attached > this is the control response I got back from the 'make testenv' > environment in Samba4. I've also attached the full LDAP request. >=20 > The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 > parsing bug). >=20 > I can make the Samba4 tree that reproduces this available as a GIT > repository if you like. =20 To reproduce: In a checkout from git://git.samba.org/abartlet/samba.git master run: OPENLDAP_ROOT=3D/usr/local/ TEST_LDAP=3Dyes make testenv Then in the xterm that pops up, run: bin/ldbsearch -H ldap://localdc1 cn=3Dadministrator --controls=3Dextended_dn:1:1 This will not return the extended DN (compare with TEST_LDAP=3Dno), because it fails to parse the returned control in libcli/ldap/ldap_controls.c (I suspect my parser also needs work) Thanks, Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-svDYOuAyXlEqIDWU48Ko Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQJosz4A8Wyi0NrsRAuLgAJwIYEfeK/rj9xXw+/2KiVhDPw6bvwCeJwaj Q/I64Xu6suP53nnqNT6Bkv0= =GSzF -----END PGP SIGNATURE----- --=-svDYOuAyXlEqIDWU48Ko--

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 10 Dec '08

10 Dec '08

--=-3DGTDdLilVnhuysLkRP/ Content-Type: multipart/mixed; boundary="=-vUh+QDuuW5KKlkVC19pp" --=-vUh+QDuuW5KKlkVC19pp Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > A tentative implementation is in HEAD, please test. You need to: Thankyou very much. I downloaded CVS HEAD and tested it out (finally - the Samba4 side of the implementation took far longer than I expected). > - configure as --enable-deref >=20 > - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > work as global overlay yet, sorry). This is something Samba4 will need, as many of our links are cross-database. But fixing this for a single DB is a big help in any case. > - run searches like > > $ ldapsearch -x -b dc=3Dexample,dc=3Dcom -E 'deref=3Dmember:entryUUID' >=20 > you'll see results like When using Samba4's client, it seems to work, but it is as if it extends the control to the full expected length, but not the data. Ie, attached this is the control response I got back from the 'make testenv' environment in Samba4. I've also attached the full LDAP request. The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 parsing bug). I can make the Samba4 tree that reproduces this available as a GIT repository if you like. =20 Thanks, Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-vUh+QDuuW5KKlkVC19pp Content-Disposition: attachment; filename=control Content-Type: application/octet-stream; name=control Content-Transfer-Encoding: base64 MIIDnzCBqAQIbWVtYmVyT2YEOGNuPUVudGVycHJpc2UgQWRtaW5zLGNuPVVzZXJzLGRjPXNhbWJh LGRjPWV4YW1wbGUsZGM9Y29toGIwMwQJZW50cnlVVUlEMSYEJGU4MmNiMjE4LTViNmEtMTAyZC05 MDk4LTU1MGYxMWFkZWE4OTArBAlvYmplY3RTaWQxHgQcAQUAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA== --=-vUh+QDuuW5KKlkVC19pp Content-Disposition: attachment; filename=request Content-Type: application/octet-stream; name=request Content-Transfer-Encoding: base64 MIINiwIBBmOBvQQaREM9c2FtYmEsREM9ZXhhbXBsZSxEQz1jb20KAQIKAQACAQACAQABAQCgKqIT oxEECWlzRGVsZXRlZAQEVFJVRaMTBAJjbgQNYWRtaW5pc3RyYXRvcjBkBAlpc0RlbGV0ZWQEAmNu BAEqBAllbnRyeVVVSUQED2NyZWF0ZVRpbWVzdGFtcAQPbW9kaWZ5VGltZXN0YW1wBA9jcmVhdGVU aW1lc3RhbXAECGVudHJ5Q1NOBAhtZW1iZXJPZqCCDMQwggzABBkxLjMuNi4xLjQuMS40MjAzLjY2 Ni41LjE2BIIMoTCCDJ0wIQQHb3duZXJCTDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAiBAhtZW1i ZXJPZjAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAtBBNub25TZWN1cml0eU1lbWJlckJMMBYECWVu dHJ5VVVJRAQJb2JqZWN0U0lEMCsEEWROUmVmZXJlbmNlVXBkYXRlMBYECWVudHJ5VVVJRAQJb2Jq ZWN0U0lEMCQECnNpdGVPYmplY3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRaXNQcml2aWxl Z2VIb2xkZXIwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRc2VydmVyUmVmZXJlbmNlQkwwFgQJ ZW50cnlVVUlEBAlvYmplY3RTSUQwJQQLZE1ETG9jYXRpb24wFgQJZW50cnlVVUlEBAlvYmplY3RT SUQwKwQRcXVlcnlQb2xpY3lPYmplY3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwIwQJYXNzaXN0 YW50MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDEEF21zRFMtTWVtYmVyc0ZvckF6Um9sZUJMMBYE CWVudHJ5VVVJRAQJb2JqZWN0U0lEMCkED2xhc3RLbm93blBhcmVudDAWBAllbnRyeVVVSUQECW9i amVjdFNJRDAnBA1mU01PUm9sZU93bmVyMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCgEDm1zQ09N LVVzZXJMaW5rMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCQECm1hc3RlcmVkQnkwFgQJZW50cnlV VUlEBAlvYmplY3RTSUQwMwQZbXNEUy1OQy1SZXBsaWNhLUxvY2F0aW9uczAWBAllbnRyeVVVSUQE CW9iamVjdFNJRDAuBBRpcHNlY0lTQUtNUFJlZmVyZW5jZTAWBAllbnRyeVVVSUQECW9iamVjdFNJ RDAhBAdzZWVBbHNvMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCYEDGhhc01hc3Rlck5DczAWBAll bnRyeVVVSUQECW9iamVjdFNJRDAuBBRmUlNNZW1iZXJSZWZlcmVuY2VCTDAWBAllbnRyeVVVSUQE CW9iamVjdFNJRDAwBBZtc0RTLVNEUmVmZXJlbmNlRG9tYWluMBYECWVudHJ5VVVJRAQJb2JqZWN0 U0lEMCoEEG5vdGlmaWNhdGlvbkxpc3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwJQQLcHJlZmVy cmVkT1UwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKQQPbXNEUy1Ob25NZW1iZXJzMBYECWVudHJ5 VVVJRAQJb2JqZWN0U0lEMC8EFW1zRFMtVGFza3NGb3JBelJvbGVCTDAWBAllbnRyeVVVSUQECW9i amVjdFNJRDArBBFpcHNlY05GQVJlZmVyZW5jZTAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAjBAlz ZWNyZXRhcnkwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwMAQWYnJpZGdlaGVhZFNlcnZlckxpc3RC TDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAqBBBySURTZXRSZWZlcmVuY2VzMBYECWVudHJ5VVVJ RAQJb2JqZWN0U0lEMDAEFmZyc0NvbXB1dGVyUmVmZXJlbmNlQkwwFgQJZW50cnlVVUlEBAlvYmpl Y3RTSUQwNAQabXNDT00tVXNlclBhcnRpdGlvblNldExpbmswFgQJZW50cnlVVUlEBAlvYmplY3RT SUQwLwQVbXNEUy1UYXNrc0ZvckF6VGFza0JMMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCMECW1h bmFnZWRCeTAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAvBBVkZWZhdWx0T2JqZWN0Q2F0ZWdvcnkw FgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRbm9uU2VjdXJpdHlNZW1iZXIwFgQJZW50cnlVVUlE BAlvYmplY3RTSUQwIAQGbWVtYmVyMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCsEEXN1YlNjaGVt YVN1YkVudHJ5MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDIEGGRlZmF1bHRMb2NhbFBvbGljeU9i amVjdDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDArBBFkeW5hbWljTERBUFNlcnZlcjAWBAllbnRy eVVVSUQECW9iamVjdFNJRDArBBFtc0RTLU5vbk1lbWJlcnNCTDAWBAllbnRyeVVVSUQECW9iamVj dFNJRDAoBA5kb21haW5Dcm9zc1JlZjAWBAllbnRyeVVVSUQECW9iamVjdFNJRDA0BBptc0RTLU9w ZXJhdGlvbnNGb3JBelJvbGVCTDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAsBBJkb21haW5Qb2xp Y3lPYmplY3QwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKAQOb2JqZWN0Q2F0ZWdvcnkwFgQJZW50 cnlVVUlEBAlvYmplY3RTSUQwLgQUaGFzUGFydGlhbFJlcGxpY2FOQ3MwFgQJZW50cnlVVUlEBAlv YmplY3RTSUQwJgQMc2l0ZU9iamVjdEJMMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMCcEDXF1ZXJ5 UG9saWN5QkwwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRZGlzdGluZ3Vpc2hlZE5hbWUwFgQJ ZW50cnlVVUlEBAlvYmplY3RTSUQwMQQXYnJpZGdlaGVhZFRyYW5zcG9ydExpc3QwFgQJZW50cnlV VUlEBAlvYmplY3RTSUQwNAQabXNEUy1PcGVyYXRpb25zRm9yQXpUYXNrQkwwFgQJZW50cnlVVUlE BAlvYmplY3RTSUQwKwQRbXNEUy1oYXNNYXN0ZXJOQ3MwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQw KwQRZGVmYXVsdENsYXNzU3RvcmUwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKwQRc2hvd0luQWRk cmVzc0Jvb2swFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwLgQUaXBzZWNPd25lcnNSZWZlcmVuY2Uw FgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKQQPc2VydmVyUmVmZXJlbmNlMBYECWVudHJ5VVVJRAQJ b2JqZWN0U0lEMCsEEW1zRFMtSGFzRG9tYWluTkNzMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMC4E FG1zRFMtT2JqZWN0UmVmZXJlbmNlMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDAEFm1zRFMtT2Jq ZWN0UmVmZXJlbmNlQkwwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwJgQMbmV0Ym9vdFNDUEJMMBYE CWVudHJ5VVVJRAQJb2JqZWN0U0lEMCkED21zRHMtbWFzdGVyZWRCeTAWBAllbnRyeVVVSUQECW9i amVjdFNJRDAwBBZtc0NPTS1QYXJ0aXRpb25TZXRMaW5rMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lE MCYEDGRlZmF1bHRHcm91cDAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAuBBRpcHNlY0ZpbHRlclJl ZmVyZW5jZTAWBAllbnRyeVVVSUQECW9iamVjdFNJRDAnBA1kaXJlY3RSZXBvcnRzMBYECWVudHJ5 VVVJRAQJb2JqZWN0U0lEMCUEC3RydXN0UGFyZW50MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMC0E E3JJRE1hbmFnZXJSZWZlcmVuY2UwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwIQQHbWFuYWdlcjAW BAllbnRyeVVVSUQECW9iamVjdFNJRDAwBBZwaHlzaWNhbExvY2F0aW9uT2JqZWN0MBYECWVudHJ5 VVVJRAQJb2JqZWN0U0lEMCEEB3N1YlJlZnMwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwIwQJcm9v dFRydXN0MBYECWVudHJ5VVVJRAQJb2JqZWN0U0lEMDkEH2lwc2VjTmVnb3RpYXRpb25Qb2xpY3lS ZWZlcmVuY2UwFgQJZW50cnlVVUlEBAlvYmplY3RTSUQwKAQObWFuYWdlZE9iamVjdHMwFgQJZW50 cnlVVUlEBAlvYmplY3RTSUQwIAQGbkNOYW1lMBYECWVudHJ5VVVJRAQJb2JqZWN0U0lE --=-vUh+QDuuW5KKlkVC19pp Content-Disposition: attachment; filename=response Content-Type: application/octet-stream; name=response Content-Transfer-Encoding: base64 MIITbwIBBmSCD54ENGNuPUFkbWluaXN0cmF0b3IsY249VXNlcnMsZGM9c2FtYmEsZGM9ZXhhbXBs ZSxkYz1jb20wgg9kMBUEAmNuMQ8EDUFkbWluaXN0cmF0b3IwRwQLZGVzY3JpcHRpb24xOAQ2QnVp bHQtaW4gYWNjb3VudCBmb3IgYWRtaW5pc3RlcmluZyB0aGUgY29tcHV0ZXIvZG9tYWluMB0EEnVz ZXJBY2NvdW50Q29udHJvbDEHBAU2NjA0ODArBAlvYmplY3RTaWQxHgQcAQUAAAAAAAUVAAAAUZnM kG8t4Wyarf059AEAADARBAphZG1pbkNvdW50MQMEATEwJwQOYWNjb3VudEV4cGlyZXMxFQQTOTIy MzM3MjAzNjg1NDc3NTgwNzAhBA5zQU1BY2NvdW50TmFtZTEPBA1BZG1pbmlzdHJhdG9yMCAEFmlz Q3JpdGljYWxTeXN0ZW1PYmplY3QxBgQEVFJVRTAcBAlzYW1iYTRSRE4xDwQNQWRtaW5pc3RyYXRv cjBDBAtvYmplY3RDbGFzczE0BAN0b3AEBnBlcnNvbgQUb3JnYW5pemF0aW9uYWxQZXJzb24EBHVz ZXIECXNhbWJhNFRvcDBTBA5vYmplY3RDYXRlZ29yeTFBBD9jbj1QZXJzb24sY249U2NoZW1hLGNu PUNvbmZpZ3VyYXRpb24sZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20wggPGBBRuVFNlY3VyaXR5 RGVzY3JpcHRvcjGCA6wEggOoAQAEgBQAAAAgAAAAAAAAADAAAAABAQAAAAAABRIAAAABAgAAAAAA BSAAAAAgAgAABAB4AxcAAAAAACQA/wEPAAEFAAAAAAAFFQAAAFGZzJBvLeFsmq39OQACAAAAABQA /wEPAAEBAAAAAAAFEgAAAAAAGAD/AQ8AAQIAAAAAAAUgAAAAJAIAAAAAFACUAAIAAQEAAAAAAAUK AAAABQAoAAABAAABAAAAUxpyqy8e0BGYGQCqAEBSmwEBAAAAAAAFCgAAAAUAKAAAAQAAAQAAAFQa cqsvHtARmBkAqgBAUpsBAQAAAAAABQoAAAAFACgAAAEAAAEAAABWGnKrLx7QEZgZAKoAQFKbAQEA AAAAAAUKAAAABQAoADAAAAABAAAAhri1d0qU0RGuvQAA+ANnwQEBAAAAAAAFCgAAAAUAKAAwAAAA AQAAALKVV+RVlNERrr0AAPgDZ8EBAQAAAAAABQoAAAAFACgAMAAAAAEAAACzlVfkVZTREa69AAD4 A2fBAQEAAAAAAAUKAAAABQAsABAAAAABAAAA+IhwA+EK0hG0IgCgyWj5OQECAAAAAAAFIAAAACkC AAAFACwAEAAAAAEAAAAAQhZMwCDQEadoAKoAbgUpAQIAAAAAAAUgAAAAKQIAAAUALAAQAAAAAQAA AEDCCrypedARkCAAwE/C1M8BAgAAAAAABSAAAAApAgAAAAAUAAAAAgABAQAAAAAABQsAAAAFACgA EAAAAAEAAABCL7pZonnQEZAgAMBPwtPPAQEAAAAAAAULAAAABQAoABAAAAABAAAAhri1d0qU0RGu vQAA+ANnwQEBAAAAAAAFCwAAAAUAKAAQAAAAAQAAALOVV+RVlNERrr0AAPgDZ8EBAQAAAAAABQsA AAAFACgAEAAAAAEAAABUAY3k+LzREYcCAMBPuWBQAQEAAAAAAAULAAAABQAoAAABAAABAAAAUxpy qy8e0BGYGQCqAEBSmwEBAAAAAAABAAAAAAUALAAQAAAAAQAAABAgIF+ledARkCAAwE/C1M8BAgAA AAAABSAAAAApAgAABQA4ADAAAAABAAAAf3qWv+YN0BGihQCqADBJ4gEFAAAAAAAFFQAAAFGZzJBv LeFsmq39OQUCAAAFACwAEAAAAAEAAAAdsalGrmBaQLfo/4pY1FbSAQIAAAAAAAUgAAAAMAIAAAUA LAAwAAAAAQAAAByatm0ilNERrr0AAPgDZ8EBAgAAAAAABSAAAAAxAgAAMBIEC2JhZFB3ZENvdW50 MQMEATAwDwQIY29kZVBhZ2UxAwQBMDASBAtjb3VudHJ5Q29kZTEDBAEwMBYED2JhZFBhc3N3b3Jk VGltZTEDBAEwMBEECmxhc3RMb2dvZmYxAwQBMDAQBAlsYXN0TG9nb24xAwQBMDAXBA5wcmltYXJ5 R3JvdXBJRDEFBAM1MTMwEQQKbG9nb25Db3VudDEDBAEwMB0EDnNBTUFjY291bnRUeXBlMQsECTgw NTMwNjM2ODAgBAp1bmljb2RlUHdkMRIEEFbmq7Kw6TnpZ8QxgOHGErcwHQQHZEJDU1B3ZDESBBBX Elb3c3RGQrJn3yLLlF4+MCIEDG50UHdkSGlzdG9yeTESBBBW5quysOk56WfEMYDhxhK3MCIEDGxt UHdkSGlzdG9yeTESBBBXElb3c3RGQrJn3yLLlF4+MIIGIgQXc3VwcGxlbWVudGFsQ3JlZGVudGlh bHMxggYFBIIGAQAAAAD0BQAAAAAAACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAA IAAgAFAAAwAgADABAQBQAHIAaQBtAGEAcgB5ADoASwBlAHIAYgBlAHIAbwBzADAzMDAwMDAwMDIw MDAwMDAzQzAwM0MwMDRDMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAzMDAwMDAwMDgwMDAwMDA4ODAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMTAwMDAwMDA4MDAwMDAwOTAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwNTMwMDQxMDA0RDAwNDIwMDQxMDAyRTAwNDUwMDU4 MDA0MTAwNEQwMDUwMDA0QzAwNDUwMDJFMDA0MzAwNEYwMDREMDA0MTAwNjQwMDZEMDA2OTAwNkUw MDY5MDA3MzAwNzQwMDcyMDA2MTAwNzQwMDZGMDA3MjAwNzk0OUNCRkJGNDBCMjM0OTc5NDlDQkZC RjQwQjIzNDkQAEAAAgBQAGEAYwBrAGEAZwBlAHMANEIwMDY1MDA3MjAwNjIwMDY1MDA3MjAwNkYw MDczMDAwMDAwNTcwMDQ0MDA2OTAwNjcwMDY1MDA3MzAwNzQwMB4AwAMBAFAAcgBpAG0AYQByAHkA OgBXAEQAaQBnAGUAcwB0ADMxMDAwMTFEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwRUI2RjczQUZC QzMzOTYxNEVFNjQ3MUZDMEVEQ0FEN0VBMTk5RThCRjEwNDc5NzJCMjE1NzUwNEM0RUM4OUJCM0M1 MERFNDc4OTk5OEQwODdCQkJCQkFFREVGMjE3OUVGRUI2RjczQUZCQzMzOTYxNEVFNjQ3MUZDMEVE Q0FEN0U4MjNERDkxRUQ2NzI1NjU3RUUxQTNDRDQ0NTFGRTZGRTFFOEU0OEEyMjYxNTYwNDcwQzkz MUQwMTAxM0I3OEYzRDI4QzI1RjU1Nzk2QzhFM0FDRjIwQURFNjZGRTMwMDY4NjNGOTA4QTE2RkZG QzZFQTAzM0Q1OTFERkQzRUJGRjlGRjI3OEU1NEM2NjQ1MzM2RTcyNUM5NkNDQkJDMUZGQkM3QTA0 QUI5QTg3NzVCQkIyRkExMEQ0RkQ0QkY0MUIxNTY1QjJFMzNCRjA4ODUzMjI2MDVDQTRERTM2NEU3 Qzg2M0Y5MDhBMTZGRkZDNkVBMDMzRDU5MURGRDNFQkZGNjI5NzU5N0MxNThBNzA4QTM4MEVDOTZE MTY0MzhERjZGMjAyQ0QwNUQ4QjcxRjgzQjBBQkY0OEMzOEFERjJGNDhBMTA0MzA1OEExNDU0RTk2 NUE0NjI5REYzMjZGMjQ4QkYxQUZFNkFDQTU0OEU0OEVBN0I1NUQ4ODJGMDY2MEE4QTMyRTI5RkQ0 RDMyMzI3Mjk1Qzk5QTUyQzA4NTY3NUZENDVCNTI2M0MxMDQ2NDhBQ0Y4QUNEQjExNDVFQ0JEQzMy OTc5RkQ4RjZCMkU0RTI0MkQ4N0JFRTlGMEREODVDMzA2NTZFQTJENTUyRjhCNEExNzQ5QTA0OTFD QTA2NDMwQkM2NjlCNjIwNDlEQTdGRkY5MzI5Nzc1RDk1QjZERTg3OUExMTg5QjM2QUNFNTlFMDEx MzNCQTJFNDM5RTJENzQ5MTYzRDI4MEI1Q0VEMDQyMEE4RTUyRERFMTkzRjRFM0Q2OUY5REQ4NThB ODBFQjI5NUY0ODEwOUQ3RDlCMkVFOUUyNzY0NTQxOTNERDgxOUUzNjg1RUVDM0VDMEI4MzRBRDQ3 OTk4NEM3MjUxNzRDNzk4NTNDNUZGMDkwRUE1Q0M0RjU5QjIzREEzOTBDMEM4MkMyRTEyMkQwOEM1 M0IxMjAzRTdDRkNBN0UzQjI2Q0Y1MkREQjczRjFBM0VGQzExQjdEREQ4M0YyREJERDgzMzY2RTM5 MEYwMkNGOQAwIgQKcHdkTGFzdFNldDEUBBIxMjg3MzQzMDg1NDAwMDAwMDAwHAQVbXNEUy1LZXlW ZXJzaW9uTnVtYmVyMQMEATEwEwQMaW5zdGFuY2VUeXBlMQMEATQwMwQJZW50cnlVVUlEMSYEJGU4 MDFjMTBjLTViNmEtMTAyZC05MDk2LTU1MGYxMWFkZWE4OTAkBA9jcmVhdGVUaW1lc3RhbXAxEQQP MjAwODEyMTEwMTAwNTRaMDYECGVudHJ5Q1NOMSoEKDIwMDgxMjExMDEwMDU0LjQwNjkzOFojMDAw MDAwIzAwMCMwMDAwMDAwJAQPbW9kaWZ5VGltZXN0YW1wMREEDzIwMDgxMjExMDEwMDU0WjCCATEE CG1lbWJlck9mMYIBIwQ4Y249RW50ZXJwcmlzZSBBZG1pbnMsY249VXNlcnMsZGM9c2FtYmEsZGM9 ZXhhbXBsZSxkYz1jb20ENGNuPVNjaGVtYSBBZG1pbnMsY249VXNlcnMsZGM9c2FtYmEsZGM9ZXhh bXBsZSxkYz1jb20ENGNuPURvbWFpbiBBZG1pbnMsY249VXNlcnMsZGM9c2FtYmEsZGM9ZXhhbXBs ZSxkYz1jb20EQmNuPUdyb3VwIFBvbGljeSBDcmVhdG9yIE93bmVycyxjbj1Vc2VycyxkYz1zYW1i YSxkYz1leGFtcGxlLGRjPWNvbQQ3Y249QWRtaW5pc3RyYXRvcnMsY249QnVpbHRpbixkYz1zYW1i YSxkYz1leGFtcGxlLGRjPWNvbaCCA8YwggPCBBkxLjMuNi4xLjQuMS40MjAzLjY2Ni41LjE2BIID ozCCA58wgagECG1lbWJlck9mBDhjbj1FbnRlcnByaXNlIEFkbWlucyxjbj1Vc2VycyxkYz1zYW1i YSxkYz1leGFtcGxlLGRjPWNvbaBiMDMECWVudHJ5VVVJRDEmBCRlODJjYjIxOC01YjZhLTEwMmQt OTA5OC01NTBmMTFhZGVhODkwKwQJb2JqZWN0U2lkMR4EHAEFAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA= --=-vUh+QDuuW5KKlkVC19pp-- --=-3DGTDdLilVnhuysLkRP/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQGs/z4A8Wyi0NrsRApYSAKCypwyLcW8Xy7h/bZm+jVgwfXsrzACgqKLt aQNMQH/eZvlH1z5jyZ7/FYA= =OLsg -----END PGP SIGNATURE----- --=-3DGTDdLilVnhuysLkRP/--

1 0

Re: (ITS#5853) LDAP search crashes when chasing multiple referrals
by ando＠sys-net.it 10 Dec '08

10 Dec '08

jsafrane(a)redhat.com wrote: > Following ldapsearch crashes when referral chasing is enabled in very unusual > environment with many AD servers referring to each other (I had to increase > refhoplimit to chase all the referrals). Thanks for the detailed report. However, IMHO, automatic referral chasing Is Broken. Clients should explicitly chase them, possibly providing some interactive means for rebinding. This is what is currently done, for example, by slapd when using slapo-chain(5), and what should be done by proxy backends as well. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2008