- openldap-bugs - openldap.org

Re: Antwort: Re: (ITS#4848) Another slapd startup segfault
by ando＠sys-net.it 26 Feb '07

26 Feb '07

Michael.Heep(a)o2.com wrote: > Hello Pierangelo, > >> ando(a)sys-net.it wrote: >> >> The above had nothing to do with your problem. Your problem is related >> to the fact that you intermixed overlay and database configuration >> statements, so the idletimeout statement after the accesslog overlay >> instantiation was causing invalid memory write (beyond the private data >> of the accesslog overlay instead of in the private data of the bdb >> database) resulting in heap corruption. > > You meant the limits option, not the idletimeout, right? Because when I > remove it slapd starts and runs properly. > But now I'm quite lost here. With that statement I intended to disable the > default limits for all users below ou=CNO-LDC when viewing the accesslog > (as it's bound to grow beyond the 500 entries sooner or later). The > manpage lists limits as a general database option, so I assumed placing it > at the end of the accesslog db options would impose these limits on it. > Now where would be the proper placement to achive that? > Under 2.3.33 in my test environment with an accesslog > 500 entries and > the limits directive at just this place in the conf everything worked as > expected. The limits was just a false track. It was idlcachesize to trigger the dangling memory access, but the root cause is the config statement ordering which triggered something much more subtle: basically, if database statements follow overlay instantiation, slapd is fooled into writing to the database (in this case back-bdb) private structure using a pointer to the overlay's (in this case accesslog) structure. This is now fixed in HEAD (thanks to Howard), but backporting to re23 may not be trivial, so please stick with strict ordering of configure statements. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Antwort: Re: (ITS#4848) Another slapd startup segfault
by Michael.Heep＠o2.com 26 Feb '07

26 Feb '07

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002D0ED3C125728E_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8gUGllcmFuZ2VsbywNCg0KPiBhbmRvQHN5cy1uZXQuaXQgd3JvdGU6DQo+DQo+IFRoZSBh Ym92ZSBoYWQgbm90aGluZyB0byBkbyB3aXRoIHlvdXIgcHJvYmxlbS4gIFlvdXIgcHJvYmxlbSBp cyByZWxhdGVkDQo+IHRvIHRoZSBmYWN0IHRoYXQgeW91IGludGVybWl4ZWQgb3ZlcmxheSBhbmQg ZGF0YWJhc2UgY29uZmlndXJhdGlvbg0KPiBzdGF0ZW1lbnRzLCBzbyB0aGUgaWRsZXRpbWVvdXQg c3RhdGVtZW50IGFmdGVyIHRoZSBhY2Nlc3Nsb2cgb3ZlcmxheQ0KPiBpbnN0YW50aWF0aW9uIHdh cyBjYXVzaW5nIGludmFsaWQgbWVtb3J5IHdyaXRlIChiZXlvbmQgdGhlIHByaXZhdGUgZGF0YQ0K PiBvZiB0aGUgYWNjZXNzbG9nIG92ZXJsYXkgaW5zdGVhZCBvZiBpbiB0aGUgcHJpdmF0ZSBkYXRh IG9mIHRoZSBiZGINCj4gZGF0YWJhc2UpIHJlc3VsdGluZyBpbiBoZWFwIGNvcnJ1cHRpb24uDQoN CllvdSBtZWFudCB0aGUgbGltaXRzIG9wdGlvbiwgbm90IHRoZSBpZGxldGltZW91dCwgcmlnaHQ/ IEJlY2F1c2Ugd2hlbiBJIA0KcmVtb3ZlIGl0IHNsYXBkIHN0YXJ0cyBhbmQgcnVucyBwcm9wZXJs eS4NCkJ1dCBub3cgSSdtIHF1aXRlIGxvc3QgaGVyZS4gV2l0aCB0aGF0IHN0YXRlbWVudCBJIGlu dGVuZGVkIHRvIGRpc2FibGUgdGhlIA0KZGVmYXVsdCBsaW1pdHMgZm9yIGFsbCB1c2VycyBiZWxv dyBvdT1DTk8tTERDIHdoZW4gdmlld2luZyB0aGUgYWNjZXNzbG9nIA0KKGFzIGl0J3MgYm91bmQg dG8gZ3JvdyBiZXlvbmQgdGhlIDUwMCBlbnRyaWVzIHNvb25lciBvciBsYXRlcikuIFRoZSANCm1h bnBhZ2UgbGlzdHMgbGltaXRzIGFzIGEgZ2VuZXJhbCBkYXRhYmFzZSBvcHRpb24sIHNvIEkgYXNz dW1lZCBwbGFjaW5nIGl0IA0KYXQgdGhlIGVuZCBvZiB0aGUgYWNjZXNzbG9nIGRiIG9wdGlvbnMg d291bGQgaW1wb3NlIHRoZXNlIGxpbWl0cyBvbiBpdC4gDQpOb3cgd2hlcmUgd291bGQgYmUgdGhl IHByb3BlciBwbGFjZW1lbnQgdG8gYWNoaXZlIHRoYXQ/DQpVbmRlciAyLjMuMzMgaW4gbXkgdGVz dCBlbnZpcm9ubWVudCB3aXRoIGFuIGFjY2Vzc2xvZyA+IDUwMCBlbnRyaWVzIGFuZCANCnRoZSBs aW1pdHMgZGlyZWN0aXZlIGF0IGp1c3QgdGhpcyBwbGFjZSBpbiB0aGUgY29uZiBldmVyeXRoaW5n IHdvcmtlZCBhcyANCmV4cGVjdGVkLg0KDQpXaXRoIGtpbmQgcmVnYXJkcy4NCk1pY2hhZWwgSGVl cA0KVE8tQ05TLUxEQw0KbzIgKEdlcm1hbnkpIEdtYkggJiBDby5PSEcNCkJlcm5lciBTdHJhw59l IDc2LCBELTYwNDM3IEZyYW5rZnVydCBhLiBNLg0KVGVsICs0OSgwKTY5LTUwMDItNjE1OA0KTW9i aWwgKzQ5KDApMTc2LTIwNjMxMzcyDQpGYXggKzQ5KDApNjktNTAwMi02MTY5DQptaWNoYWVsLmhl ZXBAbzIuY29tDQoNCm8yIChHZXJtYW55KSBHbWJIICYgQ28uIE9IRyDigKIgR2VvcmctQnJhdWNo bGUtUmluZyAyMy0yNSDigKIgODA5OTIgTcO8bmNoZW4g4oCiIA0KRGV1dHNjaGxhbmQg4oCiIHd3 dy5vMi5jb20vZGUNCg0KVXN0Li1JZC4tTnIuIERFIDgxMSA4ODkgNjM4LiBBbXRzZ2VyaWNodCBN w7xuY2hlbiBIUkEgNzAzNDMuIA0KR2VzZWxsc2NoYWZ0ZXI6IG8yIChHZXJtYW55KSBNYW5hZ2Vt ZW50IEdtYkguIEFtdHNnZXJpY2h0IE3DvG5jaGVuIEhSQiANCjEwOTA2MSB1bmQNCm8yIChHZXJt YW55KSBWZXJ3YWx0dW5ncyBHbWJILiBBbXRzZ2VyaWNodCBNw7xuY2hlbiBIUkIgMTIxMzg5LCBi ZWlkZSANCmViZW5kYS4NCkdlc2Now6RmdHNmw7xocmVyIGJlaWRlciBHZXNlbGxzY2hhZnRlcjog RHIuIGguYy4gUnVkb2xmIEdyw7ZnZXIsIA0KVm9yc2l0emVuZGVyLiBEaWV0cmljaCBCZWVzZS4g QW5kcsOpIEtyYXVzZS4gUHJvZi4gRHIuIEFsZXhhbmRlciBSw7ZkZXIuIA0KS2FybC1XaWxoZWxt IFJvaHJzZW4uIEx1dHogU2Now7xsZXIuDQoNCg== --=_alternative 002D0ED3C125728E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvIFBpZXJhbmdlbG8sPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IGFuZG9A c3lzLW5ldC5pdCB3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsg VGhlIGFib3ZlIGhhZCBub3RoaW5nIHRvIGRvIHdpdGgNCnlvdXIgcHJvYmxlbS4gJm5ic3A7WW91 ciBwcm9ibGVtIGlzIHJlbGF0ZWQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZndDsgdG8gdGhlIGZhY3QgdGhhdCB5b3UgaW50ZXJtaXhlZA0Kb3ZlcmxheSBhbmQg ZGF0YWJhc2UgY29uZmlndXJhdGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jmd0OyBzdGF0ZW1lbnRzLCBzbyB0aGUgaWRsZXRpbWVvdXQNCnN0YXRlbWVudCBh ZnRlciB0aGUgYWNjZXNzbG9nIG92ZXJsYXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZndDsgaW5zdGFudGlhdGlvbiB3YXMgY2F1c2luZyBpbnZhbGlkDQptZW1v cnkgd3JpdGUgKGJleW9uZCB0aGUgcHJpdmF0ZSBkYXRhPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IG9mIHRoZSBhY2Nlc3Nsb2cgb3ZlcmxheSBpbnN0ZWFk DQpvZiBpbiB0aGUgcHJpdmF0ZSBkYXRhIG9mIHRoZSBiZGI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgZGF0YWJhc2UpIHJlc3VsdGluZyBpbiBoZWFwIGNv cnJ1cHRpb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5Zb3UgbWVhbnQgdGhlIGxpbWl0cyBvcHRpb24sIG5vdCB0aGUNCmlkbGV0aW1lb3V0LCByaWdo dD8gQmVjYXVzZSB3aGVuIEkgcmVtb3ZlIGl0IHNsYXBkIHN0YXJ0cyBhbmQgcnVucyBwcm9wZXJs eS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJ1dCBub3cgSSdt IHF1aXRlIGxvc3QgaGVyZS4gV2l0aCB0aGF0DQpzdGF0ZW1lbnQgSSBpbnRlbmRlZCB0byBkaXNh YmxlIHRoZSBkZWZhdWx0IGxpbWl0cyBmb3IgYWxsIHVzZXJzIGJlbG93DQpvdT1DTk8tTERDIHdo ZW4gdmlld2luZyB0aGUgYWNjZXNzbG9nIChhcyBpdCdzIGJvdW5kIHRvIGdyb3cgYmV5b25kIHRo ZQ0KNTAwIGVudHJpZXMgc29vbmVyIG9yIGxhdGVyKS4gVGhlIG1hbnBhZ2UgbGlzdHMgbGltaXRz IGFzIGEgZ2VuZXJhbCBkYXRhYmFzZQ0Kb3B0aW9uLCBzbyBJIGFzc3VtZWQgcGxhY2luZyBpdCBh dCB0aGUgZW5kIG9mIHRoZSBhY2Nlc3Nsb2cgZGIgb3B0aW9ucw0Kd291bGQgaW1wb3NlIHRoZXNl IGxpbWl0cyBvbiBpdC4gTm93IHdoZXJlIHdvdWxkIGJlIHRoZSBwcm9wZXIgcGxhY2VtZW50DQp0 byBhY2hpdmUgdGhhdD88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlVuZGVyIDIuMy4zMyBpbiBteSB0ZXN0IGVudmlyb25tZW50DQp3aXRoIGFuIGFjY2Vzc2xvZyAm Z3Q7IDUwMCBlbnRyaWVzIGFuZCB0aGUgbGltaXRzIGRpcmVjdGl2ZSBhdCBqdXN0IHRoaXMNCnBs YWNlIGluIHRoZSBjb25mIGV2ZXJ5dGhpbmcgd29ya2VkIGFzIGV4cGVjdGVkLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2l0aCBraW5kIHJlZ2FyZHMu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5NaWNoYWVsIEhlZXA8 YnI+DQpUTy1DTlMtTERDPGJyPg0KbzIgKEdlcm1hbnkpIEdtYkggJmFtcDsgQ28uT0hHPGJyPg0K QmVybmVyIFN0cmHDn2UgNzYsIEQtNjA0MzcgRnJhbmtmdXJ0IGEuIE0uPGJyPg0KVGVsICs0OSgw KTY5LTUwMDItNjE1ODxicj4NCk1vYmlsICs0OSgwKTE3Ni0yMDYzMTM3Mjxicj4NCkZheCArNDko MCk2OS01MDAyLTYxNjk8YnI+DQptaWNoYWVsLmhlZXBAbzIuY29tPGJyPg0KPGJyPg0KbzIgKEdl cm1hbnkpIEdtYkggJmFtcDsgQ28uIE9IRyDigKIgR2VvcmctQnJhdWNobGUtUmluZyAyMy0yNSDi gKIgODA5OTIgTcO8bmNoZW4NCuKAoiBEZXV0c2NobGFuZCDigKIgd3d3Lm8yLmNvbS9kZTxicj4N Cjxicj4NClVzdC4tSWQuLU5yLiBERSA4MTEgODg5IDYzOC4gQW10c2dlcmljaHQgTcO8bmNoZW4g SFJBIDcwMzQzLiBHZXNlbGxzY2hhZnRlcjoNCm8yIChHZXJtYW55KSBNYW5hZ2VtZW50IEdtYkgu IEFtdHNnZXJpY2h0IE3DvG5jaGVuIEhSQiAxMDkwNjEgdW5kPGJyPg0KbzIgKEdlcm1hbnkpIFZl cndhbHR1bmdzIEdtYkguIEFtdHNnZXJpY2h0IE3DvG5jaGVuIEhSQiAxMjEzODksIGJlaWRlIGVi ZW5kYS48YnI+DQpHZXNjaMOkZnRzZsO8aHJlciBiZWlkZXIgR2VzZWxsc2NoYWZ0ZXI6IERyLiBo LmMuIFJ1ZG9sZiBHcsO2Z2VyLCBWb3JzaXR6ZW5kZXIuDQpEaWV0cmljaCBCZWVzZS4gQW5kcsOp IEtyYXVzZS4gUHJvZi4gRHIuIEFsZXhhbmRlciBSw7ZkZXIuIEthcmwtV2lsaGVsbSBSb2hyc2Vu Lg0KTHV0eiBTY2jDvGxlci48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 002D0ED3C125728E_=--

1 0

Re: (ITS#4845) Back-perl is non working
by kiwi＠oav.net 25 Feb '07

25 Feb '07

--Apple-Mail-19-845722018 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Le 25 f=E9vr. 07 =E0 17:40, Pierangelo Masarati a =E9crit : >> [...] >> Note that this "simpified" back-perl backend what working very well >> on OpenLDAP 2.2.xx branch... And the documentation doesn't seems to >> show some big changes in this part... > > The question is: have you ever read RFC2849 (LDIF specs)? I know the > answer: NO. The point is: you're developing code (back-perl =20 > scripting is > considered code development) and you don't even care to find out =20 > what the > specs say for a minimal detail like code interoperability! Have =20 > you even > looked at an LDIF example? How can you pretend to guess, by trial and > error, when your LDIF formatting will be finally accepted by a =20 > (decent) > LDIF parser? The syntax (made easy) is clear: > > <attribute name> (no space) : (space) <value> > that's it. Apparently you tried all combinations __except__ the =20 > one that > works, but looking, e.g., to the output of ldapsearch would have =20 > put you > in the right direction even without reading RFC 2849. I am sorry *but* I have tried this combination : We get a request for UID Looking for : (uid=3Dkiwi(a)oav.net) We get some results... Sending -> dn: uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet objectClass: top objectClass: kazarPerson uid: kiwi(a)oav.net cn: Nom Prenom description: Sample description uidNumber: 10 gidNumber: 10 userPassword: Password homeDirectory: /home/test mailQuota: 50 CouriermailQuota: 50S =3D> ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet,0) <=3D ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= ldif_parse_line: missing ':' after <=3D str2entry: slap_str2undef_ad(): empty AttributeDescription str2entry(dn) failed send_ldap_result: err=3D0 matched=3D"" text=3D"" conn=3D0 op=3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: activity on: 8r daemon: read activity on 8 connection_get(8) ber_dump: buf=3D0x08539150 ptr=3D0x08539150 end=3D0x08539155 len=3D5 0000: 02 01 03 42 00 ...B. conn=3D0 op=3D2 UNBIND daemon: removing 8 conn=3D0 fd=3D8 closed daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: waked daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL > Unless you can prove that back-perl LDIF parser doesn't work with =20 > decently > formatted LDIF, I'll consider this ITS closed. It *is* buggy proove me the contrary and be not so arrogant. /Xavier= --Apple-Mail-19-845722018 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJjCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggOVMIIC/qADAgECAgEAMA0GCSqGSIb3 DQEBBAUAMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UECxMLQ0EgRGl2aXNp b24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgT BVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTAeFw0wMzExMTQxNDEz MjBaFw0xMzExMTExNDEzMjBaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UE CxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFy aXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArTJ/TWJb1B9Tgg2Be6BK+KfnNCfyingorlFmQGmN lUvZ+1kK3JSWr7+N4i7oRLRv0htL+oyj7LHoL0OrXhuRdYkG6A3VN73O8Wb+rGI+1Ak2i06TNYRE 7vDtauItxGOwABWgR6Fr+2eItDd8o3+s7H1hwpOZo8zMrVfwyNQOMlcCAwEAAaOB9DCB8TAMBgNV HRMEBTADAQH/MB0GA1UdDgQWBBT7L+QPhVGztBVc65wVFYz95pkTwjCBwQYDVR0jBIG5MIG2gBT7 L+QPhVGztBVc65wVFYz95pkTwqGBmqSBlzCBlDEaMBgGA1UEChMRQXNzb2NpYXRpb24gS2F6YXIx FDASBgNVBAsTC0NBIERpdmlzaW9uMRswGQYJKoZIhvcNAQkBFgxraXdpQG9hdi5uZXQxDjAMBgNV BAcTBVBhcmlzMQ4wDAYDVQQIEwVQYXJpczELMAkGA1UEBhMCRlIxFjAUBgNVBAMTDUthemFyIFJv b3QgQ0GCAQAwDQYJKoZIhvcNAQEEBQADgYEASmOaz1/6V1um4PQSvkEqy5YgWdCoheEIHldkXUk2 Ox9FVDo9tft6S8+phoagZnXyHq6sGISq5ptLNf5BoTJSm4yqPb7W0/IlzCrMoghlYf7DS3RDKiG+ CdTta906lswo04uV8OPYyFjXYFkaxtdlxcXc/vRCdqIvO5QCEyRvGlgwggRGMIIDr6ADAgECAhBf WXY2/Lp97IQmaQuqdQ8+MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDYxNTE2NTRaFw0wODAyMDYxNTE2NTRaMIIBKTEfMB0G A1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYubmV0 MR0wGwYJKoZIhvcNAQkBFg5raXdpQDZtZWF0Lm5ldDEdMBsGCSqGSIb3DQEJARYOa2l3aUBrYXph ci5vcmcxITAfBgkqhkiG9w0BCQEWEmtpd2lAc3VwZXJmbHV4LmJpejEfMB0GCSqGSIb3DQEJARYQ a2l3aUBjYXVkaXVtLm5ldDEfMB0GCSqGSIb3DQEJARYQa2l3aS1tc25Ab2F2Lm5ldDEhMB8GCSqG SIb3DQEJARYScG9zdG1hc3RlckBvYXYubmV0MSMwIQYJKoZIhvcNAQkBFhR4YXZpZXJAYmVhdWRv dWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJdNOyX58MnQHVmyXZAiOkRd niRbx7HUUZg5picgmHOlHlAM8EEcv8tyZfaAxNndt1OtkSDlFrPdeqgbJXW6F/VNksATpxJPAXMc 0hmiiQon5qJvCAtjKTUZHPifNu8IwDHXuuOJm9Xl8dzkmzyy1XkHDnlV2yAPDiuwfV5PjgBcVJQb Pl2jncfQBFoInlfeGdZaChFQKpqIULFUAyuOhpp5vsNQqPAjCfAvGbPKZEIpom1OfBPUshzMB32E eWhG4vF+wKV4F7NlFMsSwAPas9Qil3mvUcwDigei5/nmwvxCsfyQtHCm/A0XcK5//4fKNGeSQK7W 7pkxdUKQFmCJCMsCAwEAAaOBrzCBrDCBmwYDVR0RBIGTMIGQgQxraXdpQG9hdi5uZXSBDmtpd2lA Nm1lYXQubmV0gQ5raXdpQGthemFyLm9yZ4ESa2l3aUBzdXBlcmZsdXguYml6gRBraXdpQGNhdWRp dW0ubmV0gRBraXdpLW1zbkBvYXYubmV0gRJwb3N0bWFzdGVyQG9hdi5uZXSBFHhhdmllckBiZWF1 ZG91aW4ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAA1oQbxpPOZbFEqKS4aph 2LBd+fy6nvBtFFpdgVOx3LZkU3bcXJtk2m6sJPW72sHKpU5m93uQqJCuT6s+sfI062Q3pp27EJjv 0gkIs6OpI36IOKf7zQp7qmN4YANeuE60U4hCrSlXK5uLrPguoBk72PWdPGI8hMOnfJmHa9+0YXIx ggNcMIIDWAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ X1l2Nvy6feyEJmkLqnUPPjAJBgUrDgMCGgUAoIIBuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjUxODAwNTBaMCMGCSqGSIb3DQEJBDEWBBQWG+Gb4d19rwPE aRI6PmdcJ9AsYTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6 YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0 aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAHi4NB/J3cucstsrftaOUUAQMNtT 3KEWDBGoYOmtTTDAxa48+6arC2V5DOc6Wob9M4qZOeQ3PmOYId+aq+ItQLQPtuAo7TsqtdjgMCKj JXR/k0iVobcJF1JNYEVWazm69fOtonEBQSRCwXS02NlO+amfDSLNfBuICfS9w78xDNnnIk3QDSyf GJX2M1muvJuZYCUNkSiHKmmxb9zXW4Mfp61mih1JOfrjDdwg2ZGX8NKgkuOFKlDNp/8HjAKsPAYN yA6N1zwdT4s8XjLRJIW2jZL2Xom0lYRVYPU3LmV1zb5YWXMrDElOY5YyPiTUXP0l9yhMipCIEKH0 /6On1ERVnRgAAAAAAAA= --Apple-Mail-19-845722018--

1 0

Re: (ITS#4845) Back-perl is non working
by ando＠sys-net.it 25 Feb '07

25 Feb '07

>> If the above is the way your LDIF is formatted, then back-perl >> (actually, str2entry, a helper function in the core of slapd) is >> working >> as intended. There's supposed to be no space between attribute >> names or >> "dn" and the colon ":". Please fix you PERL and report. > > I did several tests : one too less, I fear. > > - No space between attribute and data : ... > > Still getting no results. > > But there is an interressing error : "ldif_parse_line: missing ':' > after" > > So it seems that "old way" I used in OpenLDAP 2.2.xx branch doesn't > seems to be bad. ... > Note that this "simpified" back-perl backend what working very well > on OpenLDAP 2.2.xx branch... And the documentation doesn't seems to > show some big changes in this part... The question is: have you ever read RFC2849 (LDIF specs)? I know the answer: NO. The point is: you're developing code (back-perl scripting is considered code development) and you don't even care to find out what the specs say for a minimal detail like code interoperability! Have you even looked at an LDIF example? How can you pretend to guess, by trial and error, when your LDIF formatting will be finally accepted by a (decent) LDIF parser? The syntax (made easy) is clear: <attribute name> (no space) : (space) <value> that's it. Apparently you tried all combinations __except__ the one that works, but looking, e.g., to the output of ldapsearch would have put you in the right direction even without reading RFC 2849. Unless you can prove that back-perl LDIF parser doesn't work with decently formatted LDIF, I'll consider this ITS closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4845) Back-perl is non working
by kiwi＠oav.net 25 Feb '07

25 Feb '07

--Apple-Mail-17-824115749 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hi, Le 21 f=E9vr. 07 =E0 23:02, Pierangelo Masarati a =E9crit : > kiwi(a)oav.net wrote: >> Full_Name: Xavier Beaudouin >> Version: 2.3.33 >> OS: FreeBSD 6.2 >> URL: http://www.oav.net/tmp/openldap/ >> Submission from: (NULL) (82.225.248.92) > >> Sending -> dn : uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet >> objectClass : top >> objectClass : kazarPerson >> uid : kiwi(a)oav.net >> cn : Nom Prenom >> description : Sample description >> uidNumber : 10 >> gidNumber : 10 >> userPassword : Password >> homeDirectory : /home/test >> mailQuota : 50 >> CouriermailQuota : 50S >> >> str2entry: entry -1 has no dn >> str2entry(dn) failed >> send_ldap_result: err=3D0 matched=3D"" text=3D"" >> connection_get(8) > > If the above is the way your LDIF is formatted, then back-perl > (actually, str2entry, a helper function in the core of slapd) is =20 > working > as intended. There's supposed to be no space between attribute =20 > names or > "dn" and the colon ":". Please fix you PERL and report. I did several tests : - No space between attribute and data : conn=3D0 op=3D1 SRCH base=3D"ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet" scope=3D2= deref=3D0 =20 filter=3D"(uid=3Dkiwi(a)oav.net)" We get a request for UID Looking for : (uid=3Dkiwi(a)oav.net) We get some results... Sending -> dn:uid=3Dkiwi@oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet objectClass:top objectClass:kazarPerson uid:kiwi@oav.net cn:Nom Prenom description:Sample description uidNumber:10 gidNumber:10 userPassword:Password homeDirectory:/home/test mailQuota:50 CouriermailQuota:50S =3D> ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet,0) <=3D ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= ldif_parse_line: missing ':' after <=3D str2entry: slap_str2undef_ad(): empty AttributeDescription str2entry(dn) failed send_ldap_result: err=3D0 matched=3D"" text=3D"" conn=3D0 op=3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D daemon: activity on 1 descriptor daemon: activity on: 8r daemon: read activity on 8 connection_get(8) ber_dump: buf=3D0x08253a00 ptr=3D0x08253a00 end=3D0x08253a05 len=3D5 0000: 02 01 03 42 00 ...B. connection_read(8): input error=3D-2 id=3D0, closing. daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: waked daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL conn=3D0 op=3D2 UNBIND daemon: removing 8 conn=3D0 fd=3D8 closed - No space between attribute 'dn' and ':' : conn=3D0 op=3D1 SRCH base=3D"ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet" scope=3D2= deref=3D0 =20 filter=3D"(uid=3Dkiwi(a)oav.net)" We get a request for UID Looking for : (uid=3Dkiwi(a)oav.net) We get some results... Sending -> dn: uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet objectClass : top objectClass : kazarPerson uid : kiwi(a)oav.net cn : Nom Prenom description : Sample description uidNumber : 10 gidNumber : 10 userPassword : Password homeDirectory : /home/test mailQuota : 50 CouriermailQuota : 50S =3D> ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet,0) <=3D ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= ldif_parse_line: missing ':' after <=3D str2entry: slap_str2undef_ad(objectClass): AttributeDescription =20 contains inappropriate characters str2entry(dn) failed send_ldap_result: err=3D0 matched=3D"" text=3D"" conn=3D0 op=3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D daemon: activity on 1 descriptor daemon: activity on: 8r daemon: read activity on 8 connection_get(8) ber_dump: buf=3D0x08253830 ptr=3D0x08253830 end=3D0x08253835 len=3D5 0000: 02 01 03 42 00 ...B. connection_read(8): input error=3D-2 id=3D0, closing. daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: waked daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL conn=3D0 op=3D2 UNBIND daemon: removing 8 conn=3D0 fd=3D8 closed Still getting no results. But there is an interressing error : "ldif_parse_line: missing ':' =20 after" So it seems that "old way" I used in OpenLDAP 2.2.xx branch doesn't =20 seems to be bad. What are the changes in str2entry() that may change ? Here is the kind of string I sent to : my $entry =3D "dn : uid=3D$mailaddr,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet\= n\t". "objectClass : top\n\t". "objectClass : kazarPerson\n\t"; $entry .=3D "uid : $mailaddr\n\t"; $entry .=3D "cn : Nom Prenom\n\t"; $entry .=3D "description : Sample description\n\t"; $entry .=3D "uidNumber : 10\n\t"; $entry .=3D "gidNumber : 10\n\t"; $entry .=3D "userPassword : Password\n\t"; $entry .=3D "homeDirectory : /home/test\n\t"; $entry .=3D "mailQuota : 50\n\t"; $entry .=3D "CouriermailQuota : 50S\n\t"; print STDERR "Sending -> $entry\n"; push @match_entries, $entry; return(0, @match_entries); Note that this "simpified" back-perl backend what working very well =20 on OpenLDAP 2.2.xx branch... And the documentation doesn't seems to =20 show some big changes in this part... THanks, /Xavier= --Apple-Mail-17-824115749 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJjCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggOVMIIC/qADAgECAgEAMA0GCSqGSIb3 DQEBBAUAMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UECxMLQ0EgRGl2aXNp b24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgT BVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTAeFw0wMzExMTQxNDEz MjBaFw0xMzExMTExNDEzMjBaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UE CxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFy aXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArTJ/TWJb1B9Tgg2Be6BK+KfnNCfyingorlFmQGmN lUvZ+1kK3JSWr7+N4i7oRLRv0htL+oyj7LHoL0OrXhuRdYkG6A3VN73O8Wb+rGI+1Ak2i06TNYRE 7vDtauItxGOwABWgR6Fr+2eItDd8o3+s7H1hwpOZo8zMrVfwyNQOMlcCAwEAAaOB9DCB8TAMBgNV HRMEBTADAQH/MB0GA1UdDgQWBBT7L+QPhVGztBVc65wVFYz95pkTwjCBwQYDVR0jBIG5MIG2gBT7 L+QPhVGztBVc65wVFYz95pkTwqGBmqSBlzCBlDEaMBgGA1UEChMRQXNzb2NpYXRpb24gS2F6YXIx FDASBgNVBAsTC0NBIERpdmlzaW9uMRswGQYJKoZIhvcNAQkBFgxraXdpQG9hdi5uZXQxDjAMBgNV BAcTBVBhcmlzMQ4wDAYDVQQIEwVQYXJpczELMAkGA1UEBhMCRlIxFjAUBgNVBAMTDUthemFyIFJv b3QgQ0GCAQAwDQYJKoZIhvcNAQEEBQADgYEASmOaz1/6V1um4PQSvkEqy5YgWdCoheEIHldkXUk2 Ox9FVDo9tft6S8+phoagZnXyHq6sGISq5ptLNf5BoTJSm4yqPb7W0/IlzCrMoghlYf7DS3RDKiG+ CdTta906lswo04uV8OPYyFjXYFkaxtdlxcXc/vRCdqIvO5QCEyRvGlgwggRGMIIDr6ADAgECAhBf WXY2/Lp97IQmaQuqdQ8+MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDYxNTE2NTRaFw0wODAyMDYxNTE2NTRaMIIBKTEfMB0G A1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYubmV0 MR0wGwYJKoZIhvcNAQkBFg5raXdpQDZtZWF0Lm5ldDEdMBsGCSqGSIb3DQEJARYOa2l3aUBrYXph ci5vcmcxITAfBgkqhkiG9w0BCQEWEmtpd2lAc3VwZXJmbHV4LmJpejEfMB0GCSqGSIb3DQEJARYQ a2l3aUBjYXVkaXVtLm5ldDEfMB0GCSqGSIb3DQEJARYQa2l3aS1tc25Ab2F2Lm5ldDEhMB8GCSqG SIb3DQEJARYScG9zdG1hc3RlckBvYXYubmV0MSMwIQYJKoZIhvcNAQkBFhR4YXZpZXJAYmVhdWRv dWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJdNOyX58MnQHVmyXZAiOkRd niRbx7HUUZg5picgmHOlHlAM8EEcv8tyZfaAxNndt1OtkSDlFrPdeqgbJXW6F/VNksATpxJPAXMc 0hmiiQon5qJvCAtjKTUZHPifNu8IwDHXuuOJm9Xl8dzkmzyy1XkHDnlV2yAPDiuwfV5PjgBcVJQb Pl2jncfQBFoInlfeGdZaChFQKpqIULFUAyuOhpp5vsNQqPAjCfAvGbPKZEIpom1OfBPUshzMB32E eWhG4vF+wKV4F7NlFMsSwAPas9Qil3mvUcwDigei5/nmwvxCsfyQtHCm/A0XcK5//4fKNGeSQK7W 7pkxdUKQFmCJCMsCAwEAAaOBrzCBrDCBmwYDVR0RBIGTMIGQgQxraXdpQG9hdi5uZXSBDmtpd2lA Nm1lYXQubmV0gQ5raXdpQGthemFyLm9yZ4ESa2l3aUBzdXBlcmZsdXguYml6gRBraXdpQGNhdWRp dW0ubmV0gRBraXdpLW1zbkBvYXYubmV0gRJwb3N0bWFzdGVyQG9hdi5uZXSBFHhhdmllckBiZWF1 ZG91aW4ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAA1oQbxpPOZbFEqKS4aph 2LBd+fy6nvBtFFpdgVOx3LZkU3bcXJtk2m6sJPW72sHKpU5m93uQqJCuT6s+sfI062Q3pp27EJjv 0gkIs6OpI36IOKf7zQp7qmN4YANeuE60U4hCrSlXK5uLrPguoBk72PWdPGI8hMOnfJmHa9+0YXIx ggNcMIIDWAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ X1l2Nvy6feyEJmkLqnUPPjAJBgUrDgMCGgUAoIIBuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjUxMjAwNDRaMCMGCSqGSIb3DQEJBDEWBBTEQXOv2cw7Da2M Gxgl5MPnGXmD1zCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6 YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0 aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAD3RgUWLs5Si0VF628WxzJOIIzRd 3DyKLsc54IrVo60ReQxWJOS1GKH6T+r5kfbGnyhUXIwtMBpBF8Pvr6z/TlQIF+4XJKvVnW2YD3ML Rw2jHQjl8Dm73/Md+ViJ3E6PsQwkuRsONYl93CkqsET8UL1AFg9wc2fjI9vDT9SKgUzppK4nY7py aKJuTm3avopBaZyOQNrcr4LOrdWDQM/xh/n1u8VX5u3CanOum2sHyHqbcxTuHj2p3yKaxpigFiO2 L0fMc4ZY1baLuPDXHj8mbY36edl6TqxoFilGz5E9a9rVgSA5tMciRtZge2R3ZjxoaKRvCy7wNBMx iQKGpG/tL24AAAAAAAA= --Apple-Mail-17-824115749--

1 0

Re: (ITS#4851) improper database recovery at startup when using shared memory for db cache
by hyc＠symas.com 24 Feb '07

24 Feb '07

hyc(a)symas.com wrote: > erici(a)motown.cc.utexas.edu wrote: >> Full_Name: Eric Irrgang >> Version: 2.3.34 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.83.217.14) >> >> >> Using Berkeley DB 4.4.20 for the hdb backend to OpenLDAP 2.3.34 with a shared >> memory segment for the db cache, the automatic bdb database recovery fails after >> a reboot (because the shared memory segment doesn't exist yet). > > In fact there is no automatic DB recovery happening here, this is a regular > Open that fails because the (shared memory) environment is missing. We don't > detect that recovery is needed because presumably slapd exited cleanly at the > previous shutdown. > > I guess we'll have to add a check for this condition (e.g., if ENV open fails > and we're using shared memory, recover and try again). This is now fixed in HEAD, back-bdb/init.c 1.272 -- -- Howard Chu Chief Architect, 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#4851) improper database recovery at startup when using shared memory for db cache
by hyc＠symas.com 24 Feb '07

24 Feb '07

erici(a)motown.cc.utexas.edu wrote: > Full_Name: Eric Irrgang > Version: 2.3.34 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.83.217.14) > > > Using Berkeley DB 4.4.20 for the hdb backend to OpenLDAP 2.3.34 with a shared > memory segment for the db cache, the automatic bdb database recovery fails after > a reboot (because the shared memory segment doesn't exist yet). In fact there is no automatic DB recovery happening here, this is a regular Open that fails because the (shared memory) environment is missing. We don't detect that recovery is needed because presumably slapd exited cleanly at the previous shutdown. I guess we'll have to add a check for this condition (e.g., if ENV open fails and we're using shared memory, recover and try again). > slapd logs show the following: > [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): shmat: id 0: unable > to attach to shared system memory region: Invalid argument > [ID 656078 local3.debug] bdb_db_open: Database cannot be opened, err 22. Restore > from backup! > [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): > DB_ENV->lock_id_free interface requires an environment configured for the > locking subsystem > [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): txn_checkpoint > interface requires an environment configured for the transaction subsystem > [ID 881909 local3.debug] bdb_db_close: txn_checkpoint failed: Invalid argument > (22) > [ID 658289 local3.debug] backend_startup_one: bi_db_open failed! (22) > [ID 948119 local3.debug] bdb_db_close: alock_close failed > [ID 486161 local3.debug] slapd stopped. > [ID 432338 local3.debug] connections_destroy: nothing to destroy. > > > db_recover must be used to clean up the environment. It gives the message > "db_recover: shmat: id 0: unable to attach to shared system memory region: > Invalid argument" but completes with return code 0, removes the __db.001 file, > and slapd is then able to start without errors. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4851) improper database recovery at startup when using shared memory for db cache
by erici＠motown.cc.utexas.edu 24 Feb '07

24 Feb '07

Full_Name: Eric Irrgang Version: 2.3.34 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.217.14) Using Berkeley DB 4.4.20 for the hdb backend to OpenLDAP 2.3.34 with a shared memory segment for the db cache, the automatic bdb database recovery fails after a reboot (because the shared memory segment doesn't exist yet). slapd logs show the following: [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): shmat: id 0: unable to attach to shared system memory region: Invalid argument [ID 656078 local3.debug] bdb_db_open: Database cannot be opened, err 22. Restore from backup! [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): txn_checkpoint interface requires an environment configured for the transaction subsystem [ID 881909 local3.debug] bdb_db_close: txn_checkpoint failed: Invalid argument (22) [ID 658289 local3.debug] backend_startup_one: bi_db_open failed! (22) [ID 948119 local3.debug] bdb_db_close: alock_close failed [ID 486161 local3.debug] slapd stopped. [ID 432338 local3.debug] connections_destroy: nothing to destroy. db_recover must be used to clean up the environment. It gives the message "db_recover: shmat: id 0: unable to attach to shared system memory region: Invalid argument" but completes with return code 0, removes the __db.001 file, and slapd is then able to start without errors.

1 0

Re: (ITS#4792) not able to install Slapd i.e. when I install openldap it does'nt install server module
by ando＠sys-net.it 24 Feb '07

24 Feb '07

azia(a)techxact.com wrote: > Full_Name: Ahmad Zia > Version: openldap-2.3.31 > OS: Redhat ES 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.227.142.2) > > > I have successfully compiled, make openldad but when I get to the point where I > have to run "make test" it says cannot connect to the openldap server after > timing out. You should ask software usage related questions on the openldap-software mailing list. The ITS is intended to track software bugs or development issues, and you are not pointing out any evidence of software malfunction yet. > When I use this command , I get the following: > > [root@TXDXB openldap]# rpm -qa | grep openldap > openldap-devel-2.2.13-6.4E > openldap-2.2.13-6.4E > openldap-clients-2.2.13-6.4E > > its not listing openldap-server-2.2.13-6.4E and in my /etc/openldap directory I > only have ldap.conf and I do not have slapd.conf, so what I gather so far is > that I am not able to install the server module. This has nothing to do with OpenLDAP software; OpenLDAP software is released only in source form, and it's up to dofwtare distributors to package it in binary form. It is very unlikely that by simply compiling OpenLDAP software as distributed by OpenLDAP you may see anything show up with rpm -qa, since building OpenLDAP software does not result in any rpm package (and, in any case, you'd need to explicitly __install__ any rpm package to see it appear with rpm -qa). > I have used the parameter --enable-slapd with ./configure command but its still > the same thing. Slapd is built by default; the --enable-slapd switch is provided to allow users to __disable__ it. > Can you please tell me what am I doing wrong Testing may fail for hundreds of reasons beyond a bug in the software. You should check trivial things first, e.g. by inspecting any log messages resulting from the tests. See <http://www.openldap.org/faq/data/cache/1089.html> and <http://www.openldap.org/faq/data/cache/56.html> for possible directions. This ITS will be closed. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4849) LDAP URL not recognized with bind9
by ando＠sys-net.it 24 Feb '07

24 Feb '07

cyril wrote: > The message is located in > > isc_result_t dlz_ldap_checkURL(char *URL, int attrCnt, const char *msg) > > located in file bin/named/dlz_ldap_driver.c provided by > ctrix_dlz_9.3.3.patch OK. In your initial posting you claimed to be using bind 9.3.4, I assume you patched 9.3.4 with 9.3.3 patch. Anyway, in that patch I still don't see the message you reported; did you copy it verbatim, or did you elaborate it?. Anyway, that patch looks definitely similar to the analogous code in bind 9.4.0. That code seems to make use of LDAP URLs only as a means to define a LDAP search in compact form; but URLs have a specific syntax with restrictions, as indicated in RFC4516 and RFC3986; pretending to parse them with standards compliant library functions while they don't comply with their definition sounds a bit hazardous. In any case, it's astonishing that the URL syntax is used along with a marker for macro replacement that's the most reserved char in URLs. Sounds like someone chose the largest available gun to shoot in his own foot. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

RE: (ITS#4849) LDAP URL not recognized with bind9
by cyril＠coupel.net 24 Feb '07

24 Feb '07

Il s'agit d'un message ` parties multiples au format MIME. ------=_NextPart_000_0163_01C75810.9E49DBB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI =20 -----Message d'origine----- De : Pierangelo Masarati [mailto:ando@sys-net.it]=20 Envoy=E9 : vendredi 23 f=E9vrier 2007 22:02 =C0 : cyril(a)coupel.net Cc : openldap-its(a)openldap.org Objet : Re: (ITS#4849) LDAP URL not recognized with bind9 =20 cyril(a)coupel.net wrote: > Tanks for your answer. > I tested by removing the %xxxx% from the URL and the tests are passed; = but > there is an error saying that there is no %xxx% token. > I already open a case to the BIND team, but they reply this is not a = bind > problem. > However, I will transmit this information to the BIND/DLZ team. =20 I have few more comments; see below. =20 =20 > Cyril COUPEL wrote: >> I agree with this information. >> The fact is the ldapURL is not used as it, the key %zone% (or = %client%) is >> replaced with the ns domain (the client name). >>=20 >> It was working well since I upgrade to 2.3.30-r2. =20 There is no OpenLDAP 2.3.30-r2; the current version is 2.3.34. This is a Gentoo relase based on 2.3.30 (the latest relase available is 2.3.33) =20 Also, you mentioned an error message "failed to parse ldap URL"; there's no such message in bind 9.3.4 code, nor in 9.4.0rc2. Also, there's no explicit ldap_url_parse() call, so the problem could only arise when performing an operation with that broken DN. However, I don't see how the error message could be raised by bind, since the URL is parsed by bind itself, without using the OpenLDAP API function, and the DN is only used as base for other operations, so OpenLDAP API cannot have any notion of that DN being part of an URL. Finally, bind itself, while parsing the URL, checks for badly encoded portions of the URL, and the corresponding error message is "LDAP sdb zone '%s': URL: bad hex = values". =20 The message is located in =20 isc_result_t dlz_ldap_checkURL(char *URL, int attrCnt, const char *msg) located in file bin/named/dlz_ldap_driver.c provided by ctrix_dlz_9.3.3.patch =20 Could you point us to the __real__ version of OpenLDAP __and__ bind you pretend to be broken? =20 =20 p. =20 =20 =20 Ing. Pierangelo Masarati OpenLDAP Core Team =20 SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------ =20 ------=_NextPart_000_0163_01C75810.9E49DBB0 Content-Type: text/html; charset="iso-8859-1" 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=3Diso-8859-1"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style>  </style>  </head> <body lang=3DFR link=3Dblue vlink=3Dpurple> <div class=3DSection1> FYI<o:p></o:p> <o:p> </o:p> -----Message d'origine----- De : Pierangelo Masarati [mailto:ando@sys-net.it] Envoy=E9 : vendredi 23 f=E9vrier 2007 22:02 =C0 : cyril(a)coupel.net Cc : openldap-its(a)openldap.org Objet : Re: (ITS#4849) LDAP URL not recognized with = bind9<o:p></o:p> <o:p> </o:p> cyril(a)coupel.net wrote:<o:p></o:p> > Tanks for your answer.<o:p></o:p> > I tested by removing the %xxxx% from the = URL and the tests are passed; but<o:p></o:p> > there is an error saying that there is no = %xxx% token.<o:p></o:p> > I already open a case to the BIND team, but = they reply this is not a bind<o:p></o:p> > problem.<o:p></o:p> > However, I will transmit this information = to the BIND/DLZ team.<o:p></o:p> <o:p> </o:p> I have few more comments; see = below.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> > Cyril COUPEL wrote:<o:p></o:p> >> I agree with this = information.<o:p></o:p> >> The fact is the ldapURL is not used as = it, the key %zone% (or %client%) is<o:p></o:p> >> replaced with the ns domain (the client = name).<o:p></o:p> >><o:p> </o:p> >> It was working well since I upgrade to 2.3.30-r2.<o:p></o:p> <o:p> </o:p> There is no = OpenLDAP 2.3.30-r2; the current version is 2.3.34.<o:p></o:p> This = is a Gentoo relase based on 2.3.30 (the latest relase available is = 2.3.33)<o:p></o:p> <o:p> </o:p> Also, you mentioned an error message = "failed to parse ldap URL"; there's<o:p></o:p> no such message in bind 9.3.4 code, nor in = 9.4.0rc2.=A0 Also, there's no<o:p></o:p> explicit ldap_url_parse() call, so the problem = could only arise when<o:p></o:p> performing an operation with that broken DN.=A0 = However, I don't see how<o:p></o:p> the error message could be raised by bind, since = the URL is parsed by<o:p></o:p> bind itself, without using the OpenLDAP API = function, and the DN is only<o:p></o:p> used as base for other operations, so OpenLDAP = API cannot have any<o:p></o:p> notion of that DN being part of an URL.=A0 = Finally, bind itself, while<o:p></o:p> parsing the URL, checks for badly encoded = portions of the URL, and the<o:p></o:p> corresponding error message is "LDAP sdb = zone '%s': URL: bad hex values".<o:p></o:p> <o:p> </o:p> The = message is located in =A0=A0=A0 <o:p></o:p> isc_result_t dlz_ldap_checkURL(char *URL, int attrCnt, const char *msg)<o:p></o:p> located in file bin/named/dlz_ldap_driver.c provided by ctrix_dlz_9.3.3.patch<o:p></o:p> <o:p> </o:p> Could you point us to the __real__ version of = OpenLDAP __and__ bind you<o:p></o:p> pretend to be broken?<o:p></o:p> <o:p> </o:p> <o:p> </o:p> p.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Ing. Pierangelo Masarati<o:p></o:p> OpenLDAP Core Team<o:p></o:p> <o:p> </o:p> SysNet s.n.c.<o:p></o:p> Via Dossi, 8 - 27100 Pavia - = ITALIA<o:p></o:p> http://www.sys-net.it<o:p></o:p> ------------------------------------------<o:p></o:p= > Office:=A0=A0 +39.02.23998309<o:p></o:p> Mobile:=A0=A0 +39.333.4963172<o:p></o:p> Email:=A0=A0=A0 = pierangelo.masarati(a)sys-net.it<o:p></o:p> ------------------------------------------<o:p></o:p= > <o:p> </o:p> </div> </body> </html> ------=_NextPart_000_0163_01C75810.9E49DBB0--

1 0

Re: (ITS#4848) Another slapd startup segfault
by ando＠sys-net.it 24 Feb '07

24 Feb '07

ando(a)sys-net.it wrote: >> # No limits for CNO-LDC >> limits dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" size=unlimited >> time=unlimited > > Is this "time=unlimited" starting in the first column a wrap of the > mailer or is it really there? Something absurd is happening: that limit > option starting in the first column is a syntax error, but 2.3 ignores > it. What's odd is that with this syntax error I exactly get your crash, > while without it I don't get any crash. The above had nothing to do with your problem. Your problem is related to the fact that you intermixed overlay and database configuration statements, so the idletimeout statement after the accesslog overlay instantiation was causing invalid memory write (beyond the private data of the accesslog overlay instead of in the private data of the bdb database) resulting in heap corruption. Maybe it hasn't been stressed enough, but the order of directives is: - global [- global overlay [- global overlay [...] ]] [- database [- overlay [- overlay [...] ]] [- database [- overlay [- overlay [...] ]]]] and each overlay's directives have to appear before any other overlay's. I'll see if sanity checks may be added to avoid your issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4848) Another slapd startup segfault
by ando＠sys-net.it 24 Feb '07

24 Feb '07

michael.heep(a)o2.com wrote: > Full_Name: Michael Heep > Version: 2.3.34 > OS: RHES30 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.113.101.1) Just one quick question: > # No limits for CNO-LDC > limits dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" size=unlimited > time=unlimited Is this "time=unlimited" starting in the first column a wrap of the mailer or is it really there? Something absurd is happening: that limit option starting in the first column is a syntax error, but 2.3 ignores it. What's odd is that with this syntax error I exactly get your crash, while without it I don't get any crash. >From valgrind, there appears to be some invalid write and an invalid free. I keep investigating... p. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4848) Another slapd startup segfault
by ando＠sys-net.it 24 Feb '07

24 Feb '07

michael.heep(a)o2.com wrote: > Full_Name: Michael Heep > Version: 2.3.34 > OS: RHES30 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.113.101.1) Few preliminary comments: 1) could easily reproduce 2) doesn't core with HEAD/2.4 code 3) you probably don't need the unique overlay on the consumer, since it's supposed to trust consistency of data coming from the producer The direct cause of the crash is that the LDAPDN structure that's being used to rebuild a normalized string representation of the unique_base is corrupted. I'm investigating how it got corrupted. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4849) LDAP URL not recognized with bind9
by ando＠sys-net.it 23 Feb '07

23 Feb '07

cyril(a)coupel.net wrote: > Tanks for your answer. > I tested by removing the %xxxx% from the URL and the tests are passed; but > there is an error saying that there is no %xxx% token. > I already open a case to the BIND team, but they reply this is not a bind > problem. > However, I will transmit this information to the BIND/DLZ team. I have few more comments; see below. > Cyril COUPEL wrote: >> I agree with this information. >> The fact is the ldapURL is not used as it, the key %zone% (or %client%) is >> replaced with the ns domain (the client name). >> >> It was working well since I upgrade to 2.3.30-r2. There is no OpenLDAP 2.3.30-r2; the current version is 2.3.34. Also, you mentioned an error message "failed to parse ldap URL"; there's no such message in bind 9.3.4 code, nor in 9.4.0rc2. Also, there's no explicit ldap_url_parse() call, so the problem could only arise when performing an operation with that broken DN. However, I don't see how the error message could be raised by bind, since the URL is parsed by bind itself, without using the OpenLDAP API function, and the DN is only used as base for other operations, so OpenLDAP API cannot have any notion of that DN being part of an URL. Finally, bind itself, while parsing the URL, checks for badly encoded portions of the URL, and the corresponding error message is "LDAP sdb zone '%s': URL: bad hex values". Could you point us to the __real__ version of OpenLDAP __and__ bind you pretend to be broken? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4850) back-meta stops returning data
by ando＠sys-net.it 23 Feb '07

23 Feb '07

hyc(a)symas.com wrote: >> I am experiencing problems with back_meta. It does return search results for >> some time, but at some point starts returning empty search results, with SEARCH >> RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 >> minutes. > > Significant changes were made to back-meta between 2.3.32 and 2.3.33. The > current version is 2.3.34. Please upgrade and see if the issue is still present. I believe the reported behavior does no longer occur with 2.3.34. What you report seems to be related to broken behavior when the remote server closes the connection as a consequence of an idletimeout. 2.3.33 saw a lot of improvements on this side, resulting from significant development efforts and stress testing in a harsh environment, where resilience to odd target behavior was a key requirement. 2.3.34 fixed minor issues after that upgrade, and more minor fixes already are in re23 for next 2.3 release, if any. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: ITS#3812
by hyc＠symas.com 23 Feb '07

23 Feb '07

quanah(a)stanford.edu wrote: > --On Friday, February 23, 2007 7:27 PM +0000 hyc(a)symas.com wrote: > >> It might be nice to set up an automated script to pull the updated >> manpages from CVS onto the web site. > >>From CVS for the current primary release. I.e., I think it would be bad if > the manpages for 2.4 showed up right now on the website. You'll note that the web site has a selector for the release you want to view. In some respects I like the old pages being on there because their dates establish a ballpark for when a feature first appeared (well, was first documented). But I think we should always have a "Current" selection as well, that always corresponds to the latest general-use release. -- -- Howard Chu Chief Architect, 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#3812
by quanah＠stanford.edu 23 Feb '07

23 Feb '07

--On Friday, February 23, 2007 7:27 PM +0000 hyc(a)symas.com wrote: > It might be nice to set up an automated script to pull the updated > manpages from CVS onto the web site. >From CVS for the current primary release. I.e., I think it would be bad if the manpages for 2.4 showed up right now on the website. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

ITS#3812
by hyc＠symas.com 23 Feb '07

23 Feb '07

It might be nice to set up an automated script to pull the updated manpages from CVS onto the web site. -- -- Howard Chu Chief Architect, 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#4844) Missing 2.4 man pages and things marked as "Experimental"
by ghenry＠suretecsystems.com 23 Feb '07

23 Feb '07

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> <quote who="ando(a)sys-net.it"> >>> ghenry(a)suretecsystems.com wrote: >>> >>>> Just a quick to note that there are some overlays missing from >>>> slapd.overlays.5 >>>> in 2.4.4alpha and actual man pages. >>> Please enumerate them; some are intentionally not present because they >>> are not intended for real use. >> >> * dyngroup has no man page, but is listed slapd.overlays.5 >> * slapo-valsort.5 isn't in slapd.overlays.5 >> * slapo-dds.5 isn't listed in slapd.overlays.5 >> * constraint.c has no docs or listed in slapd.overlays.5 > > slapo-constraint.5 was added to CVS April 29 2006. Ok, it wasn't in the 2.4.4alpha though. > >> * seqmod.c has no docs or listed in slapd.overlays.5 > > This is a demo overlay, not intended for actual use. Ah, ok. > > -- > -- Howard Chu > Chief Architect, 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#4850) back-meta stops returning data
by hyc＠symas.com 23 Feb '07

23 Feb '07

ulf.moeller(a)secardeo.com wrote: > Full_Name: Ulf Moeller > Version: 2.3.32 > OS: SLES 9 > URL: > Submission from: (NULL) (62.245.244.226) > > > I am experiencing problems with back_meta. It does return search results for > some time, but at some point starts returning empty search results, with SEARCH > RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 > minutes. Significant changes were made to back-meta between 2.3.32 and 2.3.33. The current version is 2.3.34. Please upgrade and see if the issue is still present. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4850) back-meta stops returning data
by ulf.moeller＠secardeo.com 23 Feb '07

23 Feb '07

Full_Name: Ulf Moeller Version: 2.3.32 OS: SLES 9 URL: Submission from: (NULL) (62.245.244.226) I am experiencing problems with back_meta. It does return search results for some time, but at some point starts returning empty search results, with SEARCH RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 minutes. It doesn't return data from either of the ldap servers it is connected to. The problem also occurs in a minimal configuration with just one "uri" defined. After slapd is restarted, it again works properly for some time. When running in GDB, I get the following backtrace: Program received signal SIGPIPE, Broken pipe. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4003a55b in __write_nocancel () from /lib/tls/libpthread.so.0 #2 0x08127f34 in sb_stream_write (sbiod=0x81e69c0, buf=0x81deb60, len=64) at sockbuf.c:521 #3 0x081287b6 in sb_debug_write (sbiod=0x81e69d8, buf=0x81deb60, len=64) at sockbuf.c:820 #4 0x08127e50 in ber_int_sb_write (sb=0x81e6d38, buf=0x81deb60, len=64) at sockbuf.c:431 #5 0x08124dd6 in ber_flush (sb=0x81e6d38, ber=0x81e6e40, freeit=0) at io.c:232 #6 0x08111813 in ldap_int_flush_request (ld=0x81e6c00, lr=0x81dfb88) at request.c:151 #7 0x08111c1a in ldap_send_server_request (ld=0x81e6c00, ber=0x81e6e40, msgid=21, parentreq=0x0, srvlist=0x0, lc=0x81dfb40, bind=0x0) at request.c:301 #8 0x081117ca in ldap_send_initial_request (ld=0x81e6c00, msgtype=99, dn=0x40a1300c "", ber=0x81e6e40, msgid=21) at request.c:135 #9 0x08104661 in ldap_search_ext (ld=0x81e6c00, base=0x40a1300c "", scope=2, filter=0x81e6e18 "(mail=someone(a)domain.de)", attrs=0x0, attrsonly=0, sctrls=0x0, cctrls=0x0, timeout=0x40a10f18, sizelimit=500, msgidp=0x81e6b60) at search.c:109 #10 0x080c8194 in meta_back_search_start (op=0x40c007b0, rs=0x40a12210, dc=0x40a110f0, msc=0x81e6bb8, candidate=0, candidates=0x81e6b58) at search.c:208 #11 0x080c83f3 in meta_back_search (op=0x40c007b0, rs=0x40a12210) at search.c:285 #12 0x08063944 in fe_op_search (op=0x40c007b0, rs=0x40a12210) at search.c:355 #13 0x08063465 in do_search (op=0x40c007b0, rs=0x40a12210) at search.c:217 #14 0x08061180 in connection_operation (ctx=0x40a122a0, arg_v=0x40c007b0) at connection.c:1132 #15 0x0810052f in ldap_int_thread_pool_wrapper (xpool=0x81b8b18) at tpool.c:478 #16 0x40035cf7 in start_thread () from /lib/tls/libpthread.so.0 #17 0x400fa21e in clone () from /lib/tls/libc.so.6 #18 0x40a12bb0 in ?? () Here is an (anonymized) log: Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: >>> slap_listener(ldap://:3389) Feb 22 15:16:17 server slapd[14494]: daemon: listen=8, new connection on 11 Feb 22 15:16:17 server slapd[14494]: daemon: added 11r (active) listener=(nil) Feb 22 15:16:17 server slapd[14494]: conn=5 fd=11 ACCEPT from IP=127.0.0.1:34632 (IP=0.0.0.0 :3389) Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_bind Feb 22 15:16:17 server slapd[14494]: >>> dnPrettyNormal: <> Feb 22 15:16:17 server slapd[14494]: <<< dnPrettyNormal: <>, <> Feb 22 15:16:17 server slapd[14494]: do_bind: version=3 dn="" method=128 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 BIND dn="" method=128 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 BIND dn="" method=128 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: conn=5 op=0 p=3 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: err=0 matched="" text="" Feb 22 15:16:17 server slapd[14494]: send_ldap_response: msgid=1 tag=97 err=0 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 RESULT tag=97 err=0 text= Feb 22 15:16:17 server slapd[14494]: do_bind: v3 anonymous bind Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_search Feb 22 15:16:17 server slapd[14494]: >>> dnPrettyNormal: <> Feb 22 15:16:17 server slapd[14494]: <<< dnPrettyNormal: <>, <> Feb 22 15:16:17 server slapd[14494]: SRCH "" 2 0 Feb 22 15:16:17 server slapd[14494]: 0 0 0 Feb 22 15:16:17 server slapd[14494]: begin get_filter Feb 22 15:16:17 server slapd[14494]: EQUALITY Feb 22 15:16:17 server slapd[14494]: end get_filter 0 Feb 22 15:16:17 server slapd[14494]: filter: (mail=someone(a)domain.de) Feb 22 15:16:17 server slapd[14494]: attrs: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 SRCH base="" scope=2 deref=0 filter="(mail=someone(a)domain.de)" Feb 22 15:16:17 server slapd[14494]: ==> limits_get: conn=5 op=1 dn="[anonymous]" Feb 22 15:16:17 server slapd[14494]: conn=5 op=1: meta_back_getconn[0] Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_getconn: candidates=1 conn=-1 fet ched Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_dobind: conn=-1 Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_dobind: conn=-1 bound=1 Feb 22 15:16:17 server slapd[14494]: [rw] searchBase: "" -> "" Feb 22 15:16:17 server slapd[14494]: send_ldap_result: conn=5 op=1 p=3 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: err=32 matched="" text="" Feb 22 15:16:17 server slapd[14494]: send_ldap_response: msgid=2 tag=101 err=32 Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 SEARCH RESULT tag=101 err=32 nentries=0 tex t= Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: ber_get_next on fd 11 failed errno=0 (Success) Feb 22 15:16:17 server slapd[14494]: connection_read(11): input error=-2 id=5, closing. Feb 22 15:16:17 server slapd[14494]: connection_closing: readying conn=5 sd=11 for close Feb 22 15:16:17 server slapd[14494]: connection_close: deferring conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_unbind Feb 22 15:16:17 server slapd[14494]: conn=5 op=2 UNBIND Feb 22 15:16:17 server slapd[14494]: connection_resched: attempting closing conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: connection_close: conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: =>meta_back_conn_destroy: fetching conn=5 DN="" Feb 22 15:16:17 server slapd[14494]: daemon: removing 11 Feb 22 15:16:17 server slapd[14494]: conn=5 fd=11 closed ()

1 0

Re: (ITS#4844) Missing 2.4 man pages and things marked as "Experimental"
by hyc＠symas.com 23 Feb '07

23 Feb '07

ghenry(a)suretecsystems.com wrote: > <quote who="ando(a)sys-net.it"> >> ghenry(a)suretecsystems.com wrote: >> >>> Just a quick to note that there are some overlays missing from >>> slapd.overlays.5 >>> in 2.4.4alpha and actual man pages. >> Please enumerate them; some are intentionally not present because they >> are not intended for real use. > > * dyngroup has no man page, but is listed slapd.overlays.5 > * slapo-valsort.5 isn't in slapd.overlays.5 > * slapo-dds.5 isn't listed in slapd.overlays.5 > * constraint.c has no docs or listed in slapd.overlays.5 slapo-constraint.5 was added to CVS April 29 2006. > * seqmod.c has no docs or listed in slapd.overlays.5 This is a demo overlay, not intended for actual use. -- -- Howard Chu Chief Architect, 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#4849) LDAP URL not recognized with bind9
by cyril＠coupel.net 23 Feb '07

23 Feb '07

Tanks for your answer. I tested by removing the %xxxx% from the URL and the tests are passed; but there is an error saying that there is no %xxx% token. I already open a case to the BIND team, but they reply this is not a bind problem. However, I will transmit this information to the BIND/DLZ team. -----Message d'origine----- De : Pierangelo Masarati [mailto:ando@sys-net.it] Envoyé : vendredi 23 février 2007 12:56 À : Cyril COUPEL; openldap-its(a)openldap.org Objet : Re: (ITS#4849) LDAP URL not recognized with bind9 Please keep replies on the Issue Tracking System (ITS) list, otherwise you'll defeat its purpose of tracking issues. Cyril COUPEL wrote: > I agree with this information. > The fact is the ldapURL is not used as it, the key %zone% (or %client%) is > replaced with the ns domain (the client name). > > It was working well since I upgrade to 2.3.30-r2. > I tried to downgrade to a previous version of openldap and it was working > again, so it is a openldap problem. I see the fact that earlier versions of OpenLDAP were not compliant with standard track documents as a good reason to improve it by making it compliant, rather than a reason to keep it broken. The client is broken since it appears to parse the URL __before__ replacing portions of it that are marked using a character that is invalid in URLs. Either that client implements and uses its own broken URL parsing routines (at the risk of parsing broken URLs incorrectly, since they contain invalid characters), or it does URL parsing __after__ string replacement (i.e. after their string has been turned into a valid URL). I don't see why OpenLDAP should break (or, in this case, remain broken) to maintain compatibility with a poorly implemented client. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4849) LDAP URL not recognized with bind9
by ando＠sys-net.it 23 Feb '07

23 Feb '07

Please keep replies on the Issue Tracking System (ITS) list, otherwise you'll defeat its purpose of tracking issues. Cyril COUPEL wrote: > I agree with this information. > The fact is the ldapURL is not used as it, the key %zone% (or %client%) is > replaced with the ns domain (the client name). > > It was working well since I upgrade to 2.3.30-r2. > I tried to downgrade to a previous version of openldap and it was working > again, so it is a openldap problem. I see the fact that earlier versions of OpenLDAP were not compliant with standard track documents as a good reason to improve it by making it compliant, rather than a reason to keep it broken. The client is broken since it appears to parse the URL __before__ replacing portions of it that are marked using a character that is invalid in URLs. Either that client implements and uses its own broken URL parsing routines (at the risk of parsing broken URLs incorrectly, since they contain invalid characters), or it does URL parsing __after__ string replacement (i.e. after their string has been turned into a valid URL). I don't see why OpenLDAP should break (or, in this case, remain broken) to maintain compatibility with a poorly implemented client. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4844) Missing 2.4 man pages and things marked as "Experimental"
by ghenry＠suretecsystems.com 23 Feb '07

23 Feb '07

<quote who="ando(a)sys-net.it"> > ghenry(a)suretecsystems.com wrote: > >> Just a quick to note that there are some overlays missing from >> slapd.overlays.5 >> in 2.4.4alpha and actual man pages. > > Please enumerate them; some are intentionally not present because they > are not intended for real use. * dyngroup has no man page, but is listed slapd.overlays.5 * slapo-valsort.5 isn't in slapd.overlays.5 * slapo-dds.5 isn't listed in slapd.overlays.5 * constraint.c has no docs or listed in slapd.overlays.5 * seqmod.c has no docs or listed in slapd.overlays.5 > >> Also, relay and rwm are still marked as experimental in some places. > >> grep experimental doc/man/man5/* >> >> doc/man/man5/slapd-relay.5:This backend and the above mentioned overlay >> are >> experimental. >> >> doc/man/man5/slapo-rwm.5:This overlay is experimental. >> >> I'll help where I can, > > Sure. I believe they are no longer experimental, but they still do not > support back-config, so better wait until they're complete. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.n.c. > Via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ------------------------------------------ > Office: +39.02.23998309 > Mobile: +39.333.4963172 > Email: pierangelo.masarati(a)sys-net.it > ------------------------------------------ > > >

1 0

Re: (ITS#4849) LDAP URL not recognized with bind9
by ando＠sys-net.it 22 Feb '07

22 Feb '07

cyril_coupel(a)yahoo.fr wrote: > Full_Name: Cyril COUPEL > Version: 2.3.30-r2 > OS: Gentoo > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.241.40.178) > > > Since the openldap update 2.3.30-r2, le LDAP URL are no more recognized in the > bind 9.3.4 named.conf. > > Reproducible: Always > > Steps to Reproduce: > 1. compile BIND with DLZ and LDAP > 2. add dlz "ldap zone" { > database "ldap 2 > v3 simple {} {} {10.1.2.253} > ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz???objectclass=dlzZone ^^^ this is not a valid URL, since the two chars following each "%" are not a valid pair of hexadecimal digits, as required by URL encoding. "%" need to be URLescaped, as per RFC3986, section 2.4. The problem is in the client, not in OpenLDAP software. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4849) LDAP URL not recognized with bind9
by cyril_coupel＠yahoo.fr 22 Feb '07

22 Feb '07

Full_Name: Cyril COUPEL Version: 2.3.30-r2 OS: Gentoo URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.241.40.178) Since the openldap update 2.3.30-r2, le LDAP URL are no more recognized in the bind 9.3.4 named.conf. Reproducible: Always Steps to Reproduce: 1. compile BIND with DLZ and LDAP 2. add dlz "ldap zone" { database "ldap 2 v3 simple {} {} {10.1.2.253} ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz???objectclass=dlzZone ldap:///dlzHostName=%record%,dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType,dlzPreference,dlzData,dlzIPAddr?sub?(&(objectclass=dlzAbstractRecord)(!(dlzType=soa))) ldap:///dlzHostName=@,dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType,dlzData,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?(&(objectclass=dlzAbstractRecord)(dlzType=soa)) ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType,dlzHostName,dlzPreference,dlzData,dlzIPAddr,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?(&(objectclass=dlzAbstractRecord)(!(dlzType=soa))) ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz???(&(objectclass=dlzXFR)(dlzIPAddr=%client%)) "; }; to /etc/bind/named.conf 3. start named Actual Results: the log says :"failed to parse ldap URL" Expected Results: eb 15 16:51:35 sc1 process `named' is using obsolete setsockopt SO_BSDCOMPAT Feb 15 16:51:35 sc1 named[2220]: Loading 'ldap zone' using driver ldap Feb 15 16:51:35 sc1 named[2220]: command channel listening on 127.0.0.1#953 Feb 15 16:51:35 sc1 named[2220]: zone 127.in-addr.arpa/IN: loaded serial 2002081601 Feb 15 16:51:35 sc1 named[2220]: zone localhost/IN: loaded serial 2002081601 Feb 15 16:51:35 sc1 named[2220]: running

1 0

(ITS#4848) Another slapd startup segfault
by michael.heep＠o2.com 22 Feb '07

22 Feb '07

Full_Name: Michael Heep Version: 2.3.34 OS: RHES30 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.113.101.1) Since I'm not sure whether this is realted to my previos ITS (4847) so I'm filing another report as the OS and circumstances are different. As of 2.3.34 slapd crashes on Red Hat Enterprise 3.0 during startup. The funny thing is it only crashes on our slave, not on the master. The slave uses the following slapd.conf: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # Schema files to include include /opt/openldap/etc/schema/core.schema include /opt/openldap/etc/schema/cosine.schema include /opt/openldap/etc/schema/sudo.schema include /opt/openldap/etc/schema/nis.schema include /opt/openldap/etc/schema/openssh-lpk.schema include /opt/openldap/etc/schema/dyngroup.schema # Put those into the 'ldap' user's homedir (/var/lib/ldap) because # user 'ldap' has no write permissions in /var/run pidfile /var/lib/ldap/slapd.pid argsfile /var/lib/ldap/slapd.args # Security restrictions (all operations require at least 128bit encryption) security ssf=128 update_ssf=128 simple_bind=128 # Access control policy # rootdn can always read/write anything! # DO NOT MESS WITH THIS UNLESS YOU KNOW WHAT YOU’ARE DOING! access to dn.subtree="cn=Monitor" by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" read access to dn.subtree="cn=accesslog" by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" read access to * by dn.children="ou=Area 52,dc=o2online,dc=de" none by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" write by dn.exact="cn=syncreader,dc=o2online,dc=de" read by * break access to attrs=userPassword by self write by anonymous auth access to attrs=shadowLastChange by self write by * read access to * by * read # Logging loglevel 256 # Close idle connections after 120sec idletimeout 120 # SSL/TLS Stuff TLSCACertificateFile /opt/openldap/etc/ssl-certs/cno-ldc_ca.cert TLSCertificateFile /opt/openldap/etc/ssl-certs/sgmldap02.cert TLSCertificateKeyFile /opt/openldap/etc/ssl-keys/sgmldap02.key TLSCipherSuite HIGH TLSVerifyClient try # Chainig overlay for automatic referral chasing (global so it affects updaterefs!) # chain-uri must be EXACTLY the same as updateref (ip/host, port), otherwise it wont't work! overlay chain chain-uri "ldap://sgmldap01" chain-idassert-bind bindmethod=sasl binddn="cn=syncreader,dc=o2online,dc=de" saslmech=external mode=self chain-tls start ######################## # Database definitions # ######################## # Database for access logging database bdb suffix cn=accesslog rootdn "cn=root,cn=accesslog" rootpw {SSHA}FORBIDDEN directory /var/lib/ldap/openldap-accesslog # Indices to maintain index reqStart eq index objectClass eq # Checkpointing & caching checkpoint 256 5 cachesize 1000 idlcachesize 3000 # No limits for CNO-LDC limits dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" size=unlimited time=unlimited # Database with monitor backend for the Directory Informartion Tree database monitor database bdb suffix "dc=o2online,dc=de" rootdn "cn=root,dc=o2online,dc=de" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA} # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap/openldap-data # Accesslog overlay - Keep logs for 30 days and purge old entries once a day overlay accesslog logdb cn=accesslog logops writes logold (objectclass=*) logpurge 30+00:00 01+00:00 # Indices to maintain # WARNING: If you add indices stop slapd, run slapindex, then start slapd! # Otherwise you'll experience problems like searches returning improper results. index objectClass eq index entryCSN eq index entryUUID eq index sudoUser pres,eq,sub index uid,cn pres,eq,sub index uidNumber eq index gidNumber eq index memberUid eq index uniqueMember eq index host eq ## Syncrepl provider settings #overlay syncprov #syncprov-checkpoint 50 5 #syncprov-sessionlog 100 # Syncrepl consumer settings # Set attrs="*,+" or don't configure it at all to also replicate all operational attributes # (createTimestamp, creatorsName, modifiersName, modifyTimestamp, etc.) syncrepl rid=100 provider=ldap://sgmldap01 type=refreshAndPersist interval=00:00:00:10 retry="60 10 300 +" searchbase="dc=o2online,dc=de" filter="(objectclass=*)" scope=sub attrs="*,+" schemachecking=on starttls=critical bindmethod=sasl saslmech="external" # URL to return to clients which submit update requests updateref ldap://sgmldap01 # No limits for the "syncreader" account limits dn.exact="cn=syncreader,dc=o2online,dc=de" size=unlimited time=unlimited # Caches & Checkpointing (see slapd-bdb(5) manual) cachesize 10000 idlcachesize 30000 checkpoint 1024 5 # Attribute uniqueness overlay for POSIX accounts overlay unique unique_base "ou=People,dc=o2online,dc=de" unique_attributes uid uidNumber # Dynlist overlay to dynamically add members to groups through memberURLs overlay dynlist dynlist-attrset extensibleObject memberURL uniqueMember # Value sorting overlay overlay valsort valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend valsort-attr host dc=o2online,dc=de alpha-ascend # Allow Proxy Authorization authz-policy to # SASL rewrite rules authz-regexp email=[we want no spam](a)o2.com,cn=sgmldap([0-9]*),ou=cno-ldc,o=o2\ germany,l=frankfurt,st=hessen,c=de cn=syncreader,dc=o2online,dc=de The master's conf is basically the same. Just overlay chain + syncrepl commaneted out and overlay syncprov commented in. Uncommenting the following directives results in a clean startup: ## Syncrepl provider settings #overlay syncprov #syncprov-checkpoint 50 5 #syncprov-sessionlog 100 Here's the gdb dump: (gdb) file ./slapd Reading symbols from /home/heepm/slapd...done. Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run -u ldap -f /opt/openldap/etc/slapd.conf -h "ldap:/// ldaps:///" Starting program: /home/heepm/slapd -u ldap -f /opt/openldap/etc/slapd.conf -h "ldap:/// ldaps:///" [Thread debugging using libthread_db enabled] [New Thread -1218506624 (LWP 29908)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1218506624 (LWP 29908)] 0x0062ff95 in memmove () from /lib/tls/libc.so.6 (gdb) bt full #0 0x0062ff95 in memmove () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0817722a in rdn2str (rdn=0x901ea28, str=0x901ed12 "", flags=272, len=0x90177e2, s2s=0x8176420 <strval2str>) at getdn.c:2571 iAVA = 0 l = 3 #2 0x08177dfc in ldap_dn2bv_x (dn=0x901ebe0, bv=0x901e854, flags=272, ctx=0x0) at getdn.c:3044 rdnl = 10 iRDN = 1 rc = -3 len = 28 l = 10 sv2l = (int (*)(struct berval *, unsigned int, ber_len_t *)) 0x8176130 <strval2strlen> sv2s = (int (*)(struct berval *, char *, unsigned int, ber_len_t *)) 0x8176420 <strval2str> #3 0x08095479 in dnNormalize (use=0, syntax=0x0, mr=0x0, val=0xbfffb098, out=0x901e854, ctx=0x0) at dn.c:627 dn = 0x901ebe0 rc = 0 #4 0x081516c5 in unique_config (be=0x90177e2, fname=0x8fd9018 "/opt/openldap/etc/slapd.conf", lineno=156, argc=2, argv=0x9006ff8) at unique.c:151 bv = {bv_len = 27, bv_val = 0x901e7fd "ou=People,dc=o2online,dc=de"} on = (slap_overinst *) 0x90177e2 ud = (unique_data *) 0x901e848 up = (unique_attrs *) 0xbfffb098 text = 0xbfffb21c "/opt/openldap/etc/slapd.conf: line 156" ad = (AttributeDescription *) 0x6030a4 i = 7256760 #5 0x080ddb1a in over_db_config (be=0x901e040, fname=0x8fd9018 "/opt/openldap/etc/slapd.conf", lineno=156, argc=2, argv=0x9006ff8) at backover.c:157 on2 = (slap_overinst *) 0x0 onp = (slap_overinst **) 0x81512c0 be2 = {bd_info = 0x0, be_ctrls = '\0' <repeats 32 times>, be_flags = 0, be_restrictops = 0, be_requires = 0, be_ssf_set = { sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x0, be_nsuffix = 0x0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = {lms_t_soft = 0, lms_t_hard = 0, lms_s_soft = 0, lms_s_hard = 0, lms_s_unchecked = 0, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_NONE, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x0, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x0, be_private = 0x0, be_next = {stqe_next = 0x0}} i = 0 oi2 = (slap_overinfo *) 0x90177e2 oi = (slap_overinfo *) 0x901e4f8 on = (slap_overinst *) 0x901ebf8 be_cf_ocs = (struct ConfigOCs *) 0x82a0900 ca = {argc = 2, argv = 0x9006ff8, argv_size = 0, line = 0x0, tline = 0x0, fname = 0x8fd9018 "/opt/openldap/etc/slapd.conf", lineno = 156, log = "/opt/openldap/etc/slapd.conf: line 156", '\0' <repeats 4085 times>, msg = '\0' <repeats 255 times>, depth = 0, valx = 0, values = {v_int = 0, v_long = 0, v_ber_t = 0, v_string = 0x0, v_bv = {bv_len = 0, bv_val = 0x0}, v_dn = {vdn_dn = {bv_len = 0, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 0, ---Type <return> to continue, or q <return> to quit--- be = 0x901e040, bi = 0x0, ca_entry = 0x0, private = 0x0, cleanup = 0} rc = -1026 #6 0x0807918f in read_config_file (fname=0x8fd9018 "/opt/openldap/etc/slapd.conf", depth=0, cf=0x9007800, cft=0x829bea0) at config.c:807 fp = (FILE *) 0x9007800 ct = (ConfigTable *) 0x90177e2 c = (ConfigArgs *) 0x9005e80 rc = 151019136 s = {st_dev = 26626, __pad1 = 0, st_ino = 229380, st_mode = 33184, st_nlink = 1, st_uid = 0, st_gid = 55, st_rdev = 0, __pad2 = 0, st_size = 5199, st_blksize = 4096, st_blocks = 16, st_atim = {tv_sec = 1172158204, tv_nsec = 0}, st_mtim = { tv_sec = 1171993893, tv_nsec = 0}, st_ctim = {tv_sec = 1171993893, tv_nsec = 0}, __unused4 = 0, __unused5 = 0} #7 0x0807357e in read_config (fname=0x8fd9018 "/opt/openldap/etc/slapd.conf", dir=0x8fd9018 "/opt/openldap/etc/slapd.conf") at bconfig.c:3077 st = {st_dev = 7, __pad1 = 50360, st_ino = 135507850, st_mode = 150982944, st_nlink = 3221210280, st_uid = 1, st_gid = 150983096, st_rdev = 588336130853561644, __pad2 = 50360, st_size = 134901884, st_blksize = 136982680, st_blocks = 0, st_atim = {tv_sec = -1073756936, tv_nsec = 134933086}, st_mtim = {tv_sec = 0, tv_nsec = 24582}, st_ctim = {tv_sec = -1073756952, tv_nsec = 135684567}, __unused4 = 136990016, __unused5 = 0} be = (BackendDB *) 0x9005bb8 cfb = (CfBackInfo *) 0x9005cc0 cfdir = 0x901ea60 "\002" cfname = 0x8fd9018 "/opt/openldap/etc/slapd.conf" rc = 151018424 #8 0x0806c445 in main (argc=7, argv=0xbfffc614) at main.c:667 val = 0x0 opt = {bv_len = 3221210504, bv_val = 0x822db6e "\215\223\024\207ÿÿ\215\213\024\207ÿÿ)ÊÁú\0021ö9Ös\017\211×\220ÿ\224³\024\207ÿÿF9þrô\203Ä\f[^_ÉÃU\211åVSè"} i = 0 i = 136960888 no_detach = 0 rc = 0 urls = 0x8fd9040 "ldap:/// ldaps:///" username = 0x8fd9008 "ACI Item" groupname = 0x0 sandbox = 0x0 syslogUser = 160 configfile = 0x8fd9018 "/opt/openldap/etc/slapd.conf" configdir = 0x0 serverName = 0xbfffec31 "slapd" scp = (struct sync_cookie *) 0x829db78 scp_entry = (struct sync_cookie *) 0x90177e2 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x90177e2 "" slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 With kind regards Michael Heep

1 0

(ITS#4847) slapd segfaults on startup
by michael.heep＠o2.com 22 Feb '07

22 Feb '07

Full_Name: Michael Heep Version: 2.3.34 OS: RHES21 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.113.101.1) Since version 2.3.34 slapd simply segfaults during startup on a Red Hat Enterprise 2.1 system. I've been building a customized OpenLDAP RPM for our purposes (installs to /opt/openldap) for over a year now and never encountered any problems like this before. + CPPFLAGS= -I/usr/src/redhat/BUILD/openldap-2.3.34/db-instroot/include -I/usr/include/sasl2 + LDFLAGS= -L/usr/src/redhat/BUILD/openldap-2.3.34/db-instroot/lib + CFLAGS= -O2 -march=i386 -mcpu=i686 -D_REENTRANT -fPIC -I/usr/src/redhat/BUILD/openldap-2.3.34/db-instroot/include -I/usr/include/sasl2 -g -O2 + ./configure --prefix=/opt/openldap --exec_prefix=/opt/openldap --bindir=/opt/openldap/bin --sbindir=/opt/openldap/sbin --sysconfdir=/opt/openldap/etc --datadir=/opt/openldap/share --includedir=/opt/openldap/include --libdir=/opt/openldap/lib --libexecdir=/opt/openldap/sbin --localstatedir=/var/run --sharedstatedir=/usr/com --mandir=/opt/openldap/man --infodir=/opt/openldap/info --enable-debug --enable-bdb --enable-hdb --enable-ldap --enable-monitor --disable-ldbm --enable-slapd --disable-slurpd --enable-syncprov --enable-accesslog --enable-ppolicy --enable-unique --enable-proxycache --enable-dynlist --enable-valsort --enable-refint --with-threads --enable-shared --enable-static --enable-local --disable-rlookups --with-tls --with-cyrus-sasl --disable-wrappers --disable-ipv6 --enable-passwd --enable-crypt --enable-cleartext --enable-spasswd --enable-syslog --enable-modules --disable-sql --disable-shell Here is the stacktrace when run under gdb: (gdb) file ./slapd Load new symbol table from "./slapd"? (y or n) y Reading symbols from ./slapd...done. (gdb) run -u ldap -f /opt/openldap/etc/slapd.conf -h "ldap:/// ldaps:/// ldaps://192.168.128.204:80/" Starting program: /usr/src/redhat/BUILD/openldap-2.3.34/servers/slapd/slapd -u ldap -f /opt/openldap/etc/slapd.conf -h "ldap:/// ldaps:/// ldaps://192.168.128.204:80/" [Thread debugging using libthread_db enabled] [New Thread 8192 (LWP 30130)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 30130)] 0x08092364 in LDAPDN_rewrite (dn=0x833f618, flags=0, ctx=0x0) at dn.c:519 519 validf = ad->ad_type->sat_syntax->ssyn_validate; (gdb) bt full #0 0x08092364 in LDAPDN_rewrite (dn=0x833f618, flags=0, ctx=0x0) at dn.c:519 validf = (slap_syntax_validate_func *) 0 transf = (slap_syntax_transform_func *) 0 bv = {bv_len = 0, bv_val = 0x0} ava = (LDAPAVA *) 0x833e3a8 ad = (AttributeDescription *) 0x833e418 normf = (slap_mr_normalize_func *) 0 mr = (MatchingRule *) 0x0 do_sort = 1 iAVA = 0 iRDN = 0 rc = 2 #1 0x08092615 in dnNormalize (use=0, syntax=0x0, mr=0x0, val=0xbffeac18, out=0x833e804, ctx=0x0) at dn.c:619 val = (struct berval *) 0xbffeac18 dn = 0x833f618 rc = 137623037 #2 0x08140898 in unique_config (be=0x833f810, fname=0x82a8230 "/opt/openldap/etc/slapd.conf", lineno=168, argc=2, argv=0x833cef8) at unique.c:151 bv = {bv_len = 17, bv_val = 0x833f5fd "dc=o2online,dc=de"} be = (BackendDB *) 0x7530 on = (slap_overinst *) 0x2 ud = (unique_data *) 0x833e7f8 up = (unique_attrs *) 0xbffeac18 text = 0x101b <Address 0x101b out of bounds> ad = (AttributeDescription *) 0xbffead9c i = 137003568 #3 0x080d5c95 in over_db_config (be=0x833f810, fname=0x82a8230 "/opt/openldap/etc/slapd.conf", lineno=168, argc=2, argv=0x833cef8) at backover.c:157 oi = (slap_overinfo *) 0x833e210 on = (slap_overinst *) 0x8355c98 be_cf_ocs = (struct ConfigOCs *) 0x827f2b4 ca = {argc = 2, argv = 0x833cef8, argv_size = 0, line = 0x0, tline = 0x0, fname = 0x82a8230 "/opt/openldap/etc/slapd.conf", lineno = 168, log = "/opt/openldap/etc/slapd.conf: line 168", '\0' <repeats 4084 times>, msg = '\0' <repeats 255 times>, depth = 0, valx = 0, values = {v_int = 0, v_long = 0, v_ber_t = 0, v_string = 0x0, v_bv = {bv_len = 0, bv_val = 0x0}, v_dn = {vdn_dn = {bv_len = 0, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 0, be = 0x833f810, bi = 0x0, ca_entry = 0x0, private = 0x0, cleanup = 0} rc = -1026 #4 0x08078bbf in read_config_file (fname=0x82a8230 "/opt/openldap/etc/slapd.conf", depth=0, cf=0x0, cft=0x827a5f4) at config.c:807 fp = (FILE *) 0x833d700 ct = (ConfigTable *) 0x2 c = (ConfigArgs *) 0x833bd80 rc = -1026 s = {st_dev = 26632, __pad1 = 0, st_ino = 229391, st_mode = 33184, st_nlink = 1, st_uid = 0, st_gid = 55, st_rdev = 0, __pad2 = 0, st_size = 6040, st_blksize = 4096, st_blocks = 16, st_atime = 1172155110, __unused1 = 0, st_mtime = 1170837817, __unused2 = 0, st_ctime = 1171879479, __unused3 = 0, __unused4 = 0, __unused5 = 0} #5 0x080731fd in read_config (fname=0x82a8230 "/opt/openldap/etc/slapd.conf", dir=0x0) at bconfig.c:3077 dir = 0x82a8230 "/opt/openldap/etc/slapd.conf" be = (BackendDB *) 0x833bac8 cfb = (CfBackInfo *) 0x833bbd0 cfdir = 0x7530 <Address 0x7530 out of bounds> cfname = 0x82a8230 "/opt/openldap/etc/slapd.conf" rc = 137607880 #6 0x0806c33d in main (argc=7, argv=0xbffec1a4) at main.c:667 i = 137003568 no_detach = 0 rc = 0 urls = 0x82a8258 "ldap:/// ldaps:/// ldaps://192.168.128.204:80/" username = 0x82a8220 "HÏ,@Àò.@\020" groupname = 0x0 sandbox = 0x0 syslogUser = 160 configfile = 0x82a8230 "/opt/openldap/etc/slapd.conf" configdir = 0x0 serverName = 0xbffedbd0 "slapd" scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x2 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x2 <Address 0x2 out of bounds> slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 (gdb) (gdb) thread apply all bt Thread 1 (Thread 8192 (LWP 30130)): #0 0x08092364 in LDAPDN_rewrite (dn=0x833f618, flags=0, ctx=0x0) at dn.c:519 #1 0x08092615 in dnNormalize (use=0, syntax=0x0, mr=0x0, val=0xbffeac18, out=0x833e804, ctx=0x0) at dn.c:619 #2 0x08140898 in unique_config (be=0x833f810, fname=0x82a8230 "/opt/openldap/etc/slapd.conf", lineno=168, argc=2, argv=0x833cef8) at unique.c:151 #3 0x080d5c95 in over_db_config (be=0x833f810, fname=0x82a8230 "/opt/openldap/etc/slapd.conf", lineno=168, argc=2, argv=0x833cef8) at backover.c:157 #4 0x08078bbf in read_config_file (fname=0x82a8230 "/opt/openldap/etc/slapd.conf", depth=0, cf=0x0, cft=0x827a5f4) at config.c:807 #5 0x080731fd in read_config (fname=0x82a8230 "/opt/openldap/etc/slapd.conf", dir=0x0) at bconfig.c:3077 #6 0x0806c33d in main (argc=7, argv=0xbffec1a4) at main.c:667 (gdb) I hope this helps, since I'm not that experienced in gdb/strace usage and thus cannot make much of the output ;) OpenLDAP 2.3.33 (or lower) worked flawlessly. This is the slapd.conf we use, which hasn't changed since 2.3.32. I kept all comments, etc. to provide accurate data. Just censored the passwords: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /opt/openldap/etc/schema/core.schema include /opt/openldap/etc/schema/cosine.schema include /opt/openldap/etc/schema/sudo.schema include /opt/openldap/etc/schema/nis.schema include /opt/openldap/etc/schema/openssh-lpk.schema include /opt/openldap/etc/schema/dyngroup.schema include /opt/openldap/etc/schema/ppolicy.schema # Put those into the 'ldap' user's homedir (/var/lib/ldap) because # user 'ldap' has no write permissions in /var/run pidfile /var/lib/ldap/slapd.pid argsfile /var/lib/ldap/slapd.args # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 112-bit encryption for simple bind #security ssf=1 update_ssf=112 simple_bind=112 security ssf=128 update_ssf=128 simple_bind=128 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! access to dn.subtree="cn=accesslog" by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" read access to * by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" write by dn.exact="cn=syncreader,dc=o2online,dc=de" read by * break access to attrs=userPassword by self write by anonymous auth access to attrs=shadowLastChange by self write by * read access to * by * read # Logging loglevel 256 # Remove idle connections after 5 minutes idletimeout 300 # SSL/TLS Stuff TLSCACertificateFile /opt/openldap/etc/ssl-certs/cno-ldc_ca.cert TLSCertificateFile /opt/openldap/etc/ssl-certs/sgmldaptest02.cert TLSCertificateKeyFile /opt/openldap/etc/ssl-keys/sgmldaptest02.key TLSCipherSuite HIGH TLSVerifyClient try ## Chainig overlay for automatic referral chasing (global so it affects updateref entries!) ## chain-uri must be EXACTLY the same as updateref (ip/host, port), otherwise it wont't work! #overlay chain #chain-uri "ldap://192.168.128.205" #chain-idassert-bind bindmethod=sasl binddn="cn=syncreader,dc=o2online,dc=de" saslmech=external mode=self #chain-tls start ####################################################################### # BDB database definitions ####################################################################### # Database for access logging database bdb suffix cn=accesslog rootdn "cn=root,cn=accesslog" rootpw {SSHA}FORBIDDEN directory /var/lib/ldap/openldap-accesslog #Iindices to maintain index objectClass eq index reqStart eq # Checkpointing & caching checkpoint 256 5 cachesize 1000 idlcachesize 3000 # Main database definitions database bdb suffix "dc=o2online,dc=de" rootdn "cn=root,dc=o2online,dc=de" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA} # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap/openldap-data # Accesslog overlay - Keep logs for 30 days and purge old entries once a day overlay accesslog logdb cn=accesslog logops writes logold (objectclass=*) logpurge 30+00:00 01+00:00 # Indices to maintain # WARNING: If you add indices stop slapd, run slapindex, then start slapd! # Otherwise you'll experience problems like searches returning improper results. index objectClass eq index entryCSN eq index entryUUID eq index sudoUser pres,eq,sub index uid,cn pres,eq,sub index uidNumber eq index gidNumber eq index memberUid eq index uniqueMember eq index host eq # Syncrepl provider settings overlay syncprov syncprov-checkpoint 50 5 syncprov-sessionlog 1000 ## Syncrepl consumer settings ## Set attrs="*,+" or don't configure it at all to also replicate all operational attributes ## (createTimestamp, creatorsName, modifiersName, modifyTimestamp, etc.) #syncrepl rid=100 # provider=ldap://sgmldaptest01 # type=refreshAndPersist # interval=00:00:00:10 # retry="60 10 300 +" # searchbase="dc=o2online,dc=de" # filter="(objectclass=*)" # scope=sub # attrs="*,+" # schemachecking=on # starttls=critical # bindmethod=sasl # saslmech="external" # ## URL to return to clients which submit update requests #updateref ldap://192.168.128.205 # No limits for the "syncreader" account limits dn.exact="cn=syncreader,dc=o2online,dc=de" size=unlimited time=unlimited # Caches & Checkpointing (see slapd-bdb(5) manual) cachesize 10000 idlcachesize 30000 checkpoint 1024 5 # Attribute uniqueness overlay for POSIX accounts overlay unique unique_base "dc=o2online,dc=de" unique_attributes uid uidNumber # 2 gleiche overlays gehen nicht. Tja, was tun mit gidNumber? #overlay unique #unique_base "ou=Groups,dc=o2online,dc=de" #unique_attributes gidNumber # Dynlist overlay to dynamically add members to groups through memberURLs overlay dynlist dynlist-attrset extensibleObject memberURL uniqueMember # Valsort overlay overlay valsort valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend valsort-attr host dc=o2online,dc=de alpha-ascend # Password policy configuration overlay ppolicy #ppolicy_default "cn=Standard,ou=Password_Policies,dc=o2online,dc=de" #ppolicy_hash_cleartext ppolicy_use_lockout # Allow Proxy Authorization authz-policy to # SASL rewrite rules authz-regexp email=[we want no spam],cn=sgmldaptest([0-9]*),ou=cno-ldc,o=o2\ germany,l=frankfurt,st=hessen,c=de cn=syncreader,dc=o2online,dc=de With kind regards Michael Heep

1 0

Re: (ITS#4844) Missing 2.4 man pages and things marked as "Experimental"
by ghenry＠suretecsystems.com 21 Feb '07

21 Feb '07

<quote who="ando(a)sys-net.it"> > ghenry(a)suretecsystems.com wrote: > >> Just a quick to note that there are some overlays missing from >> slapd.overlays.5 >> in 2.4.4alpha and actual man pages. > > Please enumerate them; some are intentionally not present because they > are not intended for real use. Certainly. Will do in the morning. > >> Also, relay and rwm are still marked as experimental in some places. > >> grep experimental doc/man/man5/* >> >> doc/man/man5/slapd-relay.5:This backend and the above mentioned overlay >> are >> experimental. >> >> doc/man/man5/slapo-rwm.5:This overlay is experimental. >> >> I'll help where I can, > > Sure. I believe they are no longer experimental, but they still do not > support back-config, so better wait until they're complete. Understood. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.n.c. > Via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ------------------------------------------ > Office: +39.02.23998309 > Mobile: +39.333.4963172 > Email: pierangelo.masarati(a)sys-net.it > ------------------------------------------ > > >

1 0

Re: (ITS#4845) Back-perl is non working
by ando＠sys-net.it 21 Feb '07

21 Feb '07

kiwi(a)oav.net wrote: > Full_Name: Xavier Beaudouin > Version: 2.3.33 > OS: FreeBSD 6.2 > URL: http://www.oav.net/tmp/openldap/ > Submission from: (NULL) (82.225.248.92) > Sending -> dn : uid=kiwi(a)oav.net,ou=mailboxes,dc=kazar,dc=net > objectClass : top > objectClass : kazarPerson > uid : kiwi(a)oav.net > cn : Nom Prenom > description : Sample description > uidNumber : 10 > gidNumber : 10 > userPassword : Password > homeDirectory : /home/test > mailQuota : 50 > CouriermailQuota : 50S > > str2entry: entry -1 has no dn > str2entry(dn) failed > send_ldap_result: err=0 matched="" text="" > connection_get(8) If the above is the way your LDIF is formatted, then back-perl (actually, str2entry, a helper function in the core of slapd) is working as intended. There's supposed to be no space between attribute names or "dn" and the colon ":". Please fix you PERL and report. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4844) Missing 2.4 man pages and things marked as "Experimental"
by ando＠sys-net.it 21 Feb '07

21 Feb '07

ghenry(a)suretecsystems.com wrote: > Just a quick to note that there are some overlays missing from slapd.overlays.5 > in 2.4.4alpha and actual man pages. Please enumerate them; some are intentionally not present because they are not intended for real use. > Also, relay and rwm are still marked as experimental in some places. > grep experimental doc/man/man5/* > > doc/man/man5/slapd-relay.5:This backend and the above mentioned overlay are > experimental. > > doc/man/man5/slapo-rwm.5:This overlay is experimental. > > I'll help where I can, Sure. I believe they are no longer experimental, but they still do not support back-config, so better wait until they're complete. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

old devel bugs
by Howard Chu 21 Feb '07

21 Feb '07

Are ITS#4332 and #4473 still relevant, or can we close them? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

RE: (ITS#4846) attribute 'objectClass' provided more than once
by Wolfgang.Christ＠secunet.com 21 Feb '07

21 Feb '07

Hello Howard, i'm surely using slurpd. The replication part in slapd.conf of the master is: replogfile /home/ldap/de/secartis.replog replica uri=ldap://10.36.125.15:389 bindmethod=simple binddn="cn=admin,o=secartis,c=de" credentials=secartis attrs!=structuralObjectClass attrs!=entryUUID attrs!=creatorsName attrs!=createTimestamp attrs!=entryCSN attrs!=modifiersName attrs!=modifyTimestamp i.e. i'm using the root account for replication. And that's the mistake. I changed the binddn to a user account and now it works. Thanks a lot Kind Regards Wolfgang -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Wed 2007-02-21 14:20 To: Christ, Wolfgang Cc: openldap-its(a)openldap.org Subject: Re: (ITS#4846) attribute 'objectClass' provided more than once wolfgang.christ(a)secunet.com wrote: > Full_Name: Wolfgang Christ > Version: 2.3.32 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.68.205.167) > > > I'm trying to replicate an OpenLDAP DB using slurpd. But even a simple ldapadd > with an LDIF file like this: > > dn: cn=wolfgang,ou=organization unit,o=organization,c=de > objectClass: inetOrgPerson > objectClass: person > cn: wolfgang > sn: hilfe > userCertificate;binary:< file:///cert.crt > > OpenLDAP returns an error "attribute 'objectClass' provided more than once". If > I > remove the second objectclass with certificate and and add these in a seperate > modify step, everything is fine. > > If i modify "servers/slapd/add.c" in line 318: > > /* check for unmodifiable attributes */ > /*rs->sr_err = slap_mods_no_repl_user_mod_check( op, > modlist, &rs->sr_text, textbuf, textlen ); > if ( rs->sr_err != LDAP_SUCCESS ) { > send_ldap_result( op, rs ); > goto done; > }*/ > > and prevent calling of slap_mods_no_repl_user_mod_check(), replication works. > > Could you explain, what is the sense of slap_mods_no_repl_user_mod_check() > and why it causes slurpd not to work. Your post makes no sense. That function is only called when a normal user is trying to add an entry. It is skipped when the replication user is doing the add. So this should have nothing to do with slurpd. What are you using to perform the Add operation? Certainly OpenLDAP's ldapadd tool won't generate an error like this; it can only arise because of a malformed Add request packet. -- -- Howard Chu Chief Architect, 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#4846) attribute 'objectClass' provided more than once
by hyc＠symas.com 21 Feb '07

21 Feb '07

wolfgang.christ(a)secunet.com wrote: > Full_Name: Wolfgang Christ > Version: 2.3.32 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.68.205.167) > > > I'm trying to replicate an OpenLDAP DB using slurpd. But even a simple ldapadd > with an LDIF file like this: > > dn: cn=wolfgang,ou=organization unit,o=organization,c=de > objectClass: inetOrgPerson > objectClass: person > cn: wolfgang > sn: hilfe > userCertificate;binary:< file:///cert.crt > > OpenLDAP returns an error "attribute 'objectClass' provided more than once". If > I > remove the second objectclass with certificate and and add these in a seperate > modify step, everything is fine. > > If i modify "servers/slapd/add.c" in line 318: > > /* check for unmodifiable attributes */ > /*rs->sr_err = slap_mods_no_repl_user_mod_check( op, > modlist, &rs->sr_text, textbuf, textlen ); > if ( rs->sr_err != LDAP_SUCCESS ) { > send_ldap_result( op, rs ); > goto done; > }*/ > > and prevent calling of slap_mods_no_repl_user_mod_check(), replication works. > > Could you explain, what is the sense of slap_mods_no_repl_user_mod_check() > and why it causes slurpd not to work. Your post makes no sense. That function is only called when a normal user is trying to add an entry. It is skipped when the replication user is doing the add. So this should have nothing to do with slurpd. What are you using to perform the Add operation? Certainly OpenLDAP's ldapadd tool won't generate an error like this; it can only arise because of a malformed Add request packet. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4846) attribute 'objectClass' provided more than once
by wolfgang.christ＠secunet.com 20 Feb '07

20 Feb '07

Full_Name: Wolfgang Christ Version: 2.3.32 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.68.205.167) I'm trying to replicate an OpenLDAP DB using slurpd. But even a simple ldapadd with an LDIF file like this: dn: cn=wolfgang,ou=organization unit,o=organization,c=de objectClass: inetOrgPerson objectClass: person cn: wolfgang sn: hilfe userCertificate;binary:< file:///cert.crt OpenLDAP returns an error "attribute 'objectClass' provided more than once". If I remove the second objectclass with certificate and and add these in a seperate modify step, everything is fine. If i modify "servers/slapd/add.c" in line 318: /* check for unmodifiable attributes */ /*rs->sr_err = slap_mods_no_repl_user_mod_check( op, modlist, &rs->sr_text, textbuf, textlen ); if ( rs->sr_err != LDAP_SUCCESS ) { send_ldap_result( op, rs ); goto done; }*/ and prevent calling of slap_mods_no_repl_user_mod_check(), replication works. Could you explain, what is the sense of slap_mods_no_repl_user_mod_check() and why it causes slurpd not to work. kind regards Wolfgang Christ

1 0

Re: (ITS#4685) Updated changelog overlay by Neil Dunbar
by sebastian.rieger＠gwdg.de 20 Feb '07

20 Feb '07

This is a multi-part message in MIME format. ------=_NextPart_000_026A_01C7550D.760C6C90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I updated the changelog overlay to work with OpenLDAP up to 2.3.34, and removed some bugs from the changelog purging routine. Several stress = tests were done using 2.3.34 so it should work without problems. To ease installation of the overlay I assembled a patch, that adds the overlay = to configure, configure.in and portable.hin: Patch can be found in: ftp://ftp.openldap.org/incoming/changelog-rieger-070220.c Updated Source for the overlay: ftp://ftp.openldap.org/incoming/changelog-rieger-070220-patch.gz I'm currently working on fixing the overlay to work with OpenLDAP CVS = HEAD where the registration of the schema seems to have changed. -- MfG Sebastian Rieger Gesellschaft f=FCr wissenschaftliche Datenverarbeitung mbH G=F6ttingen=20 Am Fassberg - 37077 G=F6ttingen Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 Gesch=E4ftsf=FChrer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: G=F6ttingen Registergericht: G=F6ttingen Handelsregister-Nr. B 598 Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des = DFN =FCberpr=FCft werden: = https://ca.gwdg.de/certs/root-classic/root-ca-cert.der ------=_NextPart_000_026A_01C7550D.760C6C90 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXujCCBHUw ggNdoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNVBAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMg LSBHMDEwHhcNMDUwMjI4MDAyOTM3WhcNMTMwNDI4MDAyOTM3WjBbMQswCQYDVQQGEwJERTETMBEG A1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQ Q0EgQ2xhc3NpYyAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOvNTUXjQCVx w87yo/67c+J0bhhl6sfVNVO87Jk2WMY/lPC/E1cmq6iOAe2fV10FhexSG2zIp8XqbrlPNN7s3sy/ 0jUQfHegDqWWuCDQfWLkdWHTiDhIfhcCTdLaXDRshAxE18zDJzKPu3EMeU/N5dju7/azQVi2wkzM fM9I5aARVcrYVH+OanfQo1+yCoQupE9XaGpZRCr2w1X6pf1v0JcqakuC/LBX9uk0IPtMz9Y6frOP AvCldCn8pWNdQrT6VPmJpI7zDCm6/PCAZy82cImzkfbxGpMVxNBxC3Zwgc4zT9Cn22e0Hms8Q3cm cr8hbFb3icuGnMGKp50e9L2eOokCAwEAAaOCAUIwggE+MB0GA1UdDgQWBBSDrjvMk+EkUnrpIE+D cKIq3XsvATAfBgNVHSMEGDAWgBSDrjvMk+EkUnrpIE+DcKIq3XsvATAPBgNVHRMBAf8EBTADAQH/ MIHHBgNVHR8Egb8wgbwwXKBaoFiGVmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0 aWZpY2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMFygWqBY hlZodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1wa2kvY2VydGlmaWNhdGlvbi94NTA5L2NsYXNz aWMvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDAOBgNVHQ8BAf8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgAHMA0GCSqGSIb3DQEBBQUAA4IBAQDaFaWOgZRQO/CaU+xUQPj3mgnJ5MJug0ad1d+L k+K1iTUp8r9fLxnamypzVeVrHFbtC5zk9lxx8qDMiDc6sd9HYRJNikJUme/EfHPkzlbn6hTXuL6+ ZKdCeK3qQHnltEjg/NLUIaU/bukFmhOk6NrnU5XNTKcEeOJ47t0K2EWWZ6rN3Ji0FU444hGO73tl C5t1ACWaMYFakmylmagwdZPIVnA3qKFmVRTPcz3Cel56UyA2U6n9qQR8zZzkltIwx2/6SHt2EqQN u3g6iDyOWzIfsb0bRVHmvHQx3KCUZb5JNy3iue8yIB6WMbKZ+eJuwZl1Q0PJ87BjsHYglO3JX+Oy MIIFhjCCBG6gAwIBAgIEBnsYQDANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJERTETMBEGA1UE ChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQQ0Eg Q2xhc3NpYyAtIEcwMTAeFw0wNTA0MTIwOTUzNTRaFw0wOTA0MTIwOTUzNTRaMIGcMQswCQYDVQQG EwJERTFCMEAGA1UEChM5R2VzZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52 ZXJhcmJlaXR1bmcgbWJIMQswCQYDVQQLEwJDQTEcMBoGA1UEAxMTR1dERy1DQSBFYmVuZSAxIEcw MjEeMBwGCSqGSIb3DQEJARYPZ3dkZy1jYUBnd2RnLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA3y/2S6yGKZhpv+DwWTSH4/szbEB2yPEJUgZz5kaVId/17wKdRNKd9el03skx/ind 1IJ27YaoOybmRp5pwuNSAL7SEC2neEKcLCqkV+jDcLusV2mQ/ykgMs7No5csyhS6FxuUwBK18BlF E7tfraK3J6iyOJxzjFKB+3/ZWhasXnwEtzOUc5hRry9bTNYpyLueUa5DLR5nqIRwk1OWbx3IARbC RKrxdAupzwEAjWwz8ar2aDHgsBH41D7sfDY9wRxH04sW6K9D0BANEx+o8KhbsPQv6l0HQE7p0n6Y XQhUo5QhZ8GMfEiIh39sE1turDLut7I4bCZwrIjPT9gJqhFMWwIDAQABo4ICDjCCAgowHQYDVR0O BBYEFPP+0UOeITsrZQ3Y8arSBsKbVgajMB8GA1UdIwQYMBaAFIOuO8yT4SRSeukgT4Nwoirdey8B MA8GA1UdEwEB/wQFMAMBAf8wgccGA1UdHwSBvzCBvDBcoFqgWIZWaHR0cDovL2NkcDEucGNhLmRm bi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY3Jscy9yb290 LWNhLWNybC5jcmwwXKBaoFiGVmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0aWZp Y2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMIHcBggrBgEF BQcBAQSBzzCBzDBkBggrBgEFBQcwAoZYaHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tcGtpL2Nl cnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDBk BggrBgEFBQcwAoZYaHR0cDovL2NkcDIucGNhLmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24v eDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDAOBgNVHQ8BAf8EBAMC AQYwDQYJKoZIhvcNAQEFBQADggEBADFx3Ji676DYFd/XIY9KcsNopLqtgF5Ixr2irPOPpZ/X/zta Gss3l18EdKCCBFqhwCrd2lFOfowbxnWZ1L+WRS/+0x4a8MZoAUWyfk+pLLgv3OucY4ZhAGP5F0XJ wLRlskcnLVvt3HFQ9JsEjHo45u/QiKbZJGFPVZb5elpphRtAVTiRisw5UTiV57m07vcJhUtrt6wh 7389cz2aYYdlViMZtuaE0Z+LlSElAe4/U6tOowoR+06qDjjFNLjQ1P3fnmBPRo2zWidaLiZcfD3f qjxBgJolgeS+gS3YePj2M6NAUTu+1XKAbrFJUyrCI+qPkEcVq3yK6FkZbbhla+BKQrcwggZUMIIF PKADAgECAgou6MIgAAAAAASaMA0GCSqGSIb3DQEBBQUAMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEVi ZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFm dCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMC REUxCjAIBgNVBAUTATIwHhcNMDYxMTA5MTMzNDU3WhcNMDcwOTIwMTA1ODAwWjCBvjELMAkGA1UE BhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEzARBgNVBAcTCkdvZXR0aW5nZW4xPjA8BgNV BAoTNUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5n MRkwFwYDVQQDExBTZWJhc3RpYW4gUmllZ2VyMScwJQYJKoZIhvcNAQkBFhhzZWJhc3RpYW4ucmll Z2VyQGd3ZGcuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN+JMyvFWWLIl0gDV5t9edUF qJCNFHH/aDm40I6MZLkYZ6eyLpRVmvIQ1+KBLP8Qjagiz1HwEqwMBDNPABq50yYCHpLmKFy+BCEH r4Cjoz2AhSm4BqUhjy/XnFOqeAReo9MJfrJeslCPbfaqVV7APQl4VqALnxnDJl/1PJ4++CiLAgMB AAGjggL9MIIC+TALBgNVHQ8EBAMCBaAwNgYJKoZIhvcNAQkPBCkwJzANBggqhkiG9w0DAgIBODAN BggqhkiG9w0DBAIBODAHBgUrDgMCBzApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcKAwQwHQYDVR0OBBYEFMxqWUeIRKOu1OVQe7WDZwKzQJlGMB8GA1UdIwQYMBaAFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGvBgNVHR8EgacwgaQwgaGggZ6ggZuGTmh0dHA6Ly91c2VyLWNhLmd3 ZGcuZGUvQ2VydEVucm9sbC9HV0RHLUNBJTIwRWJlbmUlMjAyJTIwR2VuZXJpYy1DQSUyMEcwMi4x LmNybIZJaHR0cDovL3BjYS5nd2RnLmRlL2NybC9nd2RnLWNhL2ViZW5lMi9nMDIuMS9nd2RnLWNh LWViZW5lMi1nZW5lcmljLWNhLmNybDCB0wYIKwYBBQUHAQEEgcYwgcMwagYIKwYBBQUHMAGGXmh0 dHA6Ly91c2VyLWNhLmd3ZGcuZGUvQ2VydEVucm9sbC91c2VyLWNhLmd3ZGcuZGVfR1dERy1DQSUy MEViZW5lJTIwMiUyMEdlbmVyaWMtQ0ElMjBHMDIuMS5jcnQwVQYIKwYBBQUHMAGGSWh0dHA6Ly9w Y2EuZ3dkZy5kZS9jcmwvZ3dkZy1jYS9lYmVuZTIvZzAyLjEvZ3dkZy1jYS1lYmVuZTItZ2VuZXJp Yy1jYS5jcnQwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIhZ2OO4GrnU+tkQWF84sDhK7MIS2H kIMrg8myPwIBZAIBAzBKBgNVHSAEQzBBMD8GCysGAQQBgZ1IMgEBMDAwLgYIKwYBBQUHAgEWImh0 dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG0wNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMA0GCSqGSIb3DQEBBQUAA4IBAQCASq3lwDZ/ o7RuoZxqmuGCZPKlVuoBsQGaNJnoGUMBoq/7UBHRym4EpMuB8wf+NxPxhcSOxUR3UwDKE3p0VnVE O//hD6CFwbed83Wn6nv4O4jHJDxTAs0JJGomtrNxFxa5NwSUHq8ujf0DSr2Zn+yq8KzmNVjuANNe sbxvtvO3rr8pLh66m4QsgvOtGZpDeeJRpJM8eN9hf9HcIrtnCNP/KN8HGESiozUB0h0ZasH9yTQZ f/K0VCTTttPnXg3cF+g+bWMc0gGQzR40oVzTt4ggC0G68gRh2yTlQxRjMxZBS7vkWBGhEYoJoLHE TQv5oNafPL4UZGIW4SjLjWiR5mUZMIIHWzCCBkOgAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBnDEL MAkGA1UEBhMCREUxQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hl IERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UECxMCQ0ExHDAaBgNVBAMTE0dXREctQ0EgRWJl bmUgMSBHMDIxHjAcBgkqhkiG9w0BCQEWD2d3ZGctY2FAZ3dkZy5kZTAeFw0wNTA5MjAxMDU4MDBa Fw0wNzA5MjAxMDU4MDBaMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBH MDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFm dGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATIwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC62IidFd5KC11HewNoQh8DG8jcJI1fdNIf/ETt d4vOMZRRQG5+WhETBhH0d6pXjZ+V8dhlMiekFq2RpFYPictQFnEt5M49iGfX6V3PIKkaFtFTIZj0 QbGN7BWTpcCfTw6L9VwPA3olG1QYABl16Ea9mHT6nGfvwYyiadnzHCAI1XTFeF1UzOKM8EemZvGa oQncG8QUt1uqskfcLJ18ASM6GY/C108p0E9hUx2V24BQDdLdCUB6BzcW/SQdBqjRaW51mPPMxn/p bqXWrgUwkiYJOqkDY6qVUtvKGCZIumQdKxnoSB5X7tna2widH50xNX5VdMe/qnYZPLuEnbzrkOo5 AgMBAAGjggOrMIIDpzAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjBuBglghkgBhvhCAQ0E YRZfU3Vib3JkaW5hdGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHZXNlbGxzY2hhZnQgZnVl ciB3aXNzZW5zY2hhZnRsaWNoZSBEYXRlbnZlcmFyYmVpdHVuZyBtYkgwHQYDVR0OBBYEFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGGBgNVHSMEfzB9gBTz/tFDniE7K2UN2PGq0gbCm1YGo6FfpF0wWzEL MAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNV BAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMgLSBHMDGCBAZ7GEAwGgYDVR0RBBMwEYEPZ3dkZy1j YUBnd2RnLmRlMAkGA1UdEgQCMAAwQgYJYIZIAYb4QgEEBDUWM2h0dHA6Ly9jYS5nd2RnLmRlL2Ny bC9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNybDBCBglghkgBhvhCAQMENRYzaHR0cDovL2Nh Lmd3ZGcuZGUvY3JsL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3JsMIGABgNVHR8EeTB3MDmg N6A1hjNodHRwOi8vY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5jcmww OqA4oDaGNGh0dHA6Ly9wY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5j cmwwgZcGCCsGAQUFBwEBBIGKMIGHMEEGCCsGAQUFBzAChjVodHRwOi8vY2EuZ3dkZy5kZS9jZXJ0 cy9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNydDBCBggrBgEFBQcwAoY2aHR0cDovL3BjYS5n d2RnLmRlL2NlcnRzL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3J0MCAGCWCGSAGG+EIBAgQT FhFodHRwOi8vY2EuZ3dkZy5kZTAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NhLmd3ZGcuZGUvcG9s aWN5L2luZGV4Lmh0bWwwTQYDVR0gBEYwRDBCBg0rBgEEAYGdSDIBAwEBMDEwLwYIKwYBBQUHAgEW I2h0dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQBj KNeFKWGSWFjcy1fR1UHC5+MdmiTUfzHVeRbLuoGOTkbjYEbjE3+FNhGgRJJwKoDU1jQXLGGBzLQT dZcZj3QO0926SpshKNmW0zVIwf9gbAzFZ17Zgfns/BenJ7hTRl4m5aHTodkmJSKNvqwWOCFTTX9H RYRiSuDC10QYRH6S7MqyZ5Gkhtdq9iLVik8Q2RIS7OIoJgYUkLOG+tZ1rtQmWb3U6p/WwF4t5CAp ErqoJ1f427lLOj0EPOsXJUcwf+km6kkcIrKopv63HTWw7HmQHLGXajf5KbZXumwcG0Z2RCZN4OE2 yfQgRi8wmhj3pSKE4ylcz7Y9ExWdWh5YJAfMMYIDhzCCA4MCAQEwgaQwgZUxKTAnBgNVBAMTIEdX REctQ0EgRWJlbmUgMiBHZW5lcmljLUNBIEcwMi4xMQswCQYDVQQLEwJjYTFCMEAGA1UEChM5R2Vz ZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52ZXJhcmJlaXR1bmcgbWJIMQsw CQYDVQQGEwJERTEKMAgGA1UEBRMBMgIKLujCIAAAAAAEmjAJBgUrDgMCGgUAoIICODAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAyMjAxNTM3NTBaMCMGCSqGSIb3 DQEJBDEWBBRi5TY/Vy3cXYPEWqMYz4n03SV5ZjBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjAKBggqhkiG9w0CBTCBtQYJKwYBBAGCNxAEMYGnMIGkMIGVMSkwJwYDVQQDEyBHV0RH LUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2Vs bHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkG A1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowgbcGCyqGSIb3DQEJEAILMYGnoIGkMIGV MSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2Ex QjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJi ZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowDQYJKoZIhvcN AQEBBQAEgYCCe7aAZSWTEemBNF86CVX2laItjfSMajZTc0C6QRMyBVaWTRevwRApEVuGXi8tuAHD ebpepRzCWjmePfpv3RjqJbuIK5lWjA8cj1/rc7oBXFfxebCt4e3QfNbDdXKsWM/DisSGRYuVRZVj J/UWHEGT0X9jvWRpzTXWVX+pJkMGUQAAAAAAAA== ------=_NextPart_000_026A_01C7550D.760C6C90--

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by timo＠physik.uni-potsdam.de 20 Feb '07

20 Feb '07

--pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, OpenLDAP issue ITS#4750 is still unresolved (it affects current versions of nss_ldap and pam_ldap), and I consider it to be pretty serious: - Even security-conscious applications like pam_ldap still parse files from unsafe locations, including the current directory. - Attempting to read from a file in the current directory can cause problems on its own, e.g. when the directory is an autofs mountpoint (In fact, I became aware of this issue by investigating deadlocks occurring in such a situation) - If an application uses LDAP in more than one context, like a program using LDAP while also linking to nss_ldap and pam_ldap, the settings can interfere (unless very much care is taken, see below). This is bad, as the very purpose of nss and pam is to make the underlying mechanisms completely transparent to the application. - The existing LDAPNOINIT mechanism is only effective for the first call which initializes the global option structure. Thus, almost no one can reliably use it: the options may already have been initialized e.g. by nss_ldap which nearly every program might link to. The suggested workaround so far is to force nss_ldap, pam_ldap, and possibly others, to override all relevant options with safe values. To me, this seems to be quite error-prone and not a satisfactory solution: - it requires duplication of much of the configuration parsing code, which needs to be kept in sync with OpenLDAP's syntax and semantics (or worse, allow the syntax to diverge), and - it requires users to think of and nail down each and every potentially relevant option separately (note that current versions of libldap and pam_ldap silently ignore syntax errors in the config file, so one may very easily be in a false sense of security). - It does not stop libldap from opening files it shouldn't open in the first place. As Kurt Zeilenga already noted, a proper solution will require some redesign, so... I include 3 patches: one for libldap (against HEAD as of 20070216), and corresponding patches for nss_ldap-254 and pam_ldap-183. The first lines of the openldap patch (the changes to ldap.h) and the nss_ldap patch should tell you how it is supposed to work: libraries can obtain a private copy of the "globaloptions", in an opaque "LDAPContext" object, to be initialized in a safe way and independently from other copies of that structure. The existing struct globaloptions is used by default to stay compatible with existing programs. I'm willing to write more documentation too but I would like to get some some feedback on it first, Regards, Timo Felbinger --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="openldap.patch" This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Timo Felbinger <timo(a)physik.uni-potsdam.de>. These modifications are not subject to any license of University of Potsdam. I, Timo Felbinger, 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. diff -Nru openldap-src/include/ldap.h openldap-src-context/include/ldap.h --- openldap-src/include/ldap.h 2007-02-12 10:53:59.000000000 +0000 +++ openldap-src-context/include/ldap.h 2007-02-17 13:22:45.000000000 +0000 @@ -696,6 +696,8 @@ */ typedef struct ldap LDAP; +typedef struct ldapoptions LDAPContext; + #define LDAP_DEREF_NEVER 0x00 #define LDAP_DEREF_SEARCHING 0x01 #define LDAP_DEREF_FINDING 0x02 @@ -890,6 +892,12 @@ int option, LDAP_CONST void *invalue)); +LDAP_F( int ) +ldap_set_option_in_context LDAP_P(( + LDAPContext *context, + int option, + LDAP_CONST void *invalue)); + /* V3 REBIND Function Callback Prototype */ typedef int (LDAP_REBIND_PROC) LDAP_P(( LDAP *ld, LDAP_CONST char *url, @@ -1382,10 +1390,30 @@ LDAP **ldp )); LDAP_F( int ) +ldap_create_in_context LDAP_P(( + LDAP **ldp, + LDAPContext *context )); + +LDAP_F( int ) ldap_initialize LDAP_P(( LDAP **ldp, LDAP_CONST char *url )); +LDAP_F( int ) +ldap_initialize_in_context LDAP_P(( + LDAP **ldp, + LDAP_CONST char *url, + LDAPContext *context )); + +LDAP_F( int ) +ldap_create_context LDAP_P(( + LDAPContext **context, + char **directives )); + +LDAP_F( int ) +ldap_destroy_context LDAP_P(( + LDAPContext *context )); + /* * in tls.c */ diff -Nru openldap-src/include/ldap_pvt.h openldap-src-context/include/ldap_pvt.h --- openldap-src/include/ldap_pvt.h 2007-02-12 03:20:24.000000000 +0000 +++ openldap-src-context/include/ldap_pvt.h 2007-02-17 13:22:45.000000000 +0000 @@ -278,6 +278,8 @@ int option, void *arg )); LDAP_F (int) ldap_pvt_tls_set_option LDAP_P(( struct ldap *ld, int option, void *arg )); +LDAP_F (int) ldap_pvt_tls_set_option_2 LDAP_P(( struct ldapoptions *lo, struct ldap *ld, + int option, void *arg )); LDAP_F (void) ldap_pvt_tls_destroy LDAP_P(( void )); LDAP_F (int) ldap_pvt_tls_init LDAP_P(( void )); diff -Nru openldap-src/libraries/libldap/init.c openldap-src-context/libraries/libldap/init.c --- openldap-src/libraries/libldap/init.c 2007-02-05 19:32:44.000000000 +0000 +++ openldap-src-context/libraries/libldap/init.c 2007-02-17 13:22:45.000000000 +0000 @@ -124,6 +124,7 @@ #define MAX_LDAP_ENV_PREFIX_LEN 8 static void openldap_ldap_init_w_conf( + struct ldapoptions *gopts, const char *file, int userconf ) { char linebuf[ AC_LINE_MAX ]; @@ -131,10 +132,11 @@ int i; char *cmd, *opt; char *start, *end; - struct ldapoptions *gopts; - if ((gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { - return; /* Could not allocate mem for global options */ + if( ! gopts ) { + if ((gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { + return; /* Could not allocate mem for global options */ + } } if (file == NULL) { @@ -244,7 +246,7 @@ * (char**) p = LDAP_STRDUP(opt); break; case ATTR_OPTION: - ldap_set_option( NULL, attrs[i].offset, opt ); + ldap_set_option_in_context( gopts, attrs[i].offset, opt ); break; case ATTR_SASL: #ifdef HAVE_CYRUS_SASL @@ -253,7 +255,7 @@ break; case ATTR_TLS: #ifdef HAVE_TLS - ldap_int_tls_config( NULL, attrs[i].offset, opt ); + ldap_int_tls_config_in_context( gopts, attrs[i].offset, opt ); #endif break; case ATTR_OPT_TV: { @@ -285,7 +287,7 @@ static void openldap_ldap_init_w_sysconf(const char *file) { - openldap_ldap_init_w_conf( file, 0 ); + openldap_ldap_init_w_conf( NULL, file, 0 ); } static void openldap_ldap_init_w_userconf(const char *file) @@ -314,11 +316,11 @@ /* try ~/file */ sprintf(path, "%s" LDAP_DIRSEP "%s", home, file); - openldap_ldap_init_w_conf(path, 1); + openldap_ldap_init_w_conf(NULL, path, 1); /* try ~/.file */ sprintf(path, "%s" LDAP_DIRSEP ".%s", home, file); - openldap_ldap_init_w_conf(path, 1); + openldap_ldap_init_w_conf(NULL, path, 1); } if(path != NULL) { @@ -326,7 +328,7 @@ } /* try file */ - openldap_ldap_init_w_conf(file, 1); + openldap_ldap_init_w_conf(NULL, file, 1); } static void openldap_ldap_init_w_env( @@ -466,9 +468,10 @@ void ldap_int_initialize_global_options( struct ldapoptions *gopts, int *dbglvl ) { if (dbglvl) - gopts->ldo_debug = *dbglvl; + /* FIXME: currently ldo_debug is an always global option only, so we set both places: */ + gopts->ldo_debug = LDAP_INT_GLOBAL_OPT()->ldo_debug = *dbglvl; else - gopts->ldo_debug = 0; + gopts->ldo_debug = LDAP_INT_GLOBAL_OPT()->ldo_debug = 0; gopts->ldo_version = LDAP_VERSION2; gopts->ldo_deref = LDAP_DEREF_NEVER; @@ -531,7 +534,10 @@ char * ldap_int_hostname = NULL; #endif -void ldap_int_initialize( struct ldapoptions *gopts, int *dbglvl ) +void ldap_int_initialize( + struct ldapoptions *gopts, + int *dbglvl, + char **directives ) { if ( gopts->ldo_valid == LDAP_INITIALIZED ) { return; @@ -593,6 +599,19 @@ ldap_int_initialize_global_options(gopts, NULL); + if( directives ) { + for( ; *directives; ++directives ) { + if( ! strncmp( *directives, "file=", 5 ) ) { + openldap_ldap_init_w_conf( gopts, *directives + 5, 1 ); + continue; + } + /* add more directives here... */ + gopts->ldo_valid = LDAP_TRASHED_SESSION; + return; + } + return; + } + if( getenv("LDAPNOINIT") != NULL ) { return; } diff -Nru openldap-src/libraries/libldap/ldap-int.h openldap-src-context/libraries/libldap/ldap-int.h --- openldap-src/libraries/libldap/ldap-int.h 2007-02-15 00:42:23.000000000 +0000 +++ openldap-src-context/libraries/libldap/ldap-int.h 2007-02-17 13:22:45.000000000 +0000 @@ -417,7 +417,7 @@ LDAP_V ( struct ldapoptions ) ldap_int_global_options; -LDAP_F ( void ) ldap_int_initialize LDAP_P((struct ldapoptions *, int *)); +LDAP_F ( void ) ldap_int_initialize LDAP_P((struct ldapoptions *, int *, char **directives )); LDAP_F ( void ) ldap_int_initialize_global_options LDAP_P(( struct ldapoptions *, int *)); @@ -652,6 +652,9 @@ LDAP_F (int) ldap_int_tls_config LDAP_P(( LDAP *ld, int option, const char *arg )); +LDAP_F (int) ldap_int_tls_config_in_context LDAP_P(( struct ldapoptions *lo, + int option, const char *arg )); + LDAP_F (int) ldap_int_tls_start LDAP_P(( LDAP *ld, LDAPConn *conn, LDAPURLDesc *srv )); diff -Nru openldap-src/libraries/libldap/open.c openldap-src-context/libraries/libldap/open.c --- openldap-src/libraries/libldap/open.c 2007-02-12 03:20:24.000000000 +0000 +++ openldap-src-context/libraries/libldap/open.c 2007-02-17 13:45:19.000000000 +0000 @@ -87,27 +87,88 @@ return ld; } +int +ldap_free_context_internals( LDAPContext *context ) +{ + ldap_free_urllist( context->ldo_defludp ); +#ifdef HAVE_CYRUS_SASL + LDAP_FREE( context->ldo_def_sasl_authzid ); + LDAP_FREE( context->ldo_def_sasl_authcid ); + LDAP_FREE( context->ldo_def_sasl_realm ); + LDAP_FREE( context->ldo_def_sasl_mech ); +#endif + return LDAP_SUCCESS; +} + +/* public destructor of LDAPContext */ +int +ldap_destroy_context( LDAPContext *context ) +{ + if( context ) { + ldap_free_context_internals( context ); + free( context ); + } + return LDAP_SUCCESS; +} + +/* public constructor of LDAPContext */ +int +ldap_create_context( + LDAPContext **context, + /* directives: NULL-terminated list of initialization directives: + * - NULL: default initialization procedure (see ldap.conf(5)) + * - { NULL }: equivalent to LDAPNOINIT + * - { ..., "file=path", ... }: parse path like user-config file + */ + char **directives ) +{ + LDAPContext *lo; + + *context = NULL; + lo = ( LDAPContext * ) LDAP_CALLOC( 1, sizeof( LDAPContext ) ); + if( ! lo ) + return LDAP_NO_MEMORY; + + Debug( LDAP_DEBUG_TRACE, "ldap_create_context %p\n", lo, 0, 0 ); + + lo->ldo_valid = LDAP_UNINITIALIZED; + ldap_int_initialize( lo, NULL, directives ); + if( lo->ldo_valid != LDAP_INITIALIZED ) + return LDAP_LOCAL_ERROR; + *context = lo; + + return LDAP_SUCCESS; +} int ldap_create( LDAP **ldp ) { + return ldap_create_in_context( ldp, NULL ); +} + +int +ldap_create_in_context( LDAP **ldp, LDAPContext *gopts ) +{ LDAP *ld; - struct ldapoptions *gopts; *ldp = NULL; - /* Get pointer to global option structure */ - if ( (gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { - return LDAP_NO_MEMORY; - } - /* Initialize the global options, if not already done. */ - if( gopts->ldo_valid != LDAP_INITIALIZED ) { - ldap_int_initialize(gopts, NULL); - if ( gopts->ldo_valid != LDAP_INITIALIZED ) - return LDAP_LOCAL_ERROR; + if( ! gopts ) { + /* default is the global context */ + if ( (gopts = LDAP_INT_GLOBAL_OPT()) == NULL) { + return LDAP_NO_MEMORY; + } + + /* Initialize the global options, if not already done. */ + if( gopts->ldo_valid != LDAP_INITIALIZED ) { + ldap_int_initialize(gopts, NULL, NULL); + } } + if( gopts->ldo_valid != LDAP_INITIALIZED ) + return LDAP_LOCAL_ERROR; + Debug( LDAP_DEBUG_TRACE, "ldap_create\n", 0, 0, 0 ); if ( (ld = (LDAP *) LDAP_CALLOC( 1, sizeof(LDAP) )) == NULL ) { @@ -167,13 +228,7 @@ nomem: ldap_free_select_info( ld->ld_selectinfo ); - ldap_free_urllist( ld->ld_options.ldo_defludp ); -#ifdef HAVE_CYRUS_SASL - LDAP_FREE( ld->ld_options.ldo_def_sasl_authzid ); - LDAP_FREE( ld->ld_options.ldo_def_sasl_authcid ); - LDAP_FREE( ld->ld_options.ldo_def_sasl_realm ); - LDAP_FREE( ld->ld_options.ldo_def_sasl_mech ); -#endif + ldap_free_context_internals( &ld->ld_options ); LDAP_FREE( (char *)ld ); return LDAP_NO_MEMORY; } @@ -215,11 +270,17 @@ int ldap_initialize( LDAP **ldp, LDAP_CONST char *url ) { + return ldap_initialize_in_context( ldp, url, NULL ); +} + +int +ldap_initialize_in_context( LDAP **ldp, LDAP_CONST char *url, LDAPContext *context ) +{ int rc; LDAP *ld; *ldp = NULL; - rc = ldap_create(&ld); + rc = ldap_create_in_context(&ld, context); if ( rc != LDAP_SUCCESS ) return rc; diff -Nru openldap-src/libraries/libldap/options.c openldap-src-context/libraries/libldap/options.c --- openldap-src/libraries/libldap/options.c 2007-02-06 22:02:47.000000000 +0000 +++ openldap-src-context/libraries/libldap/options.c 2007-02-17 13:22:45.000000000 +0000 @@ -97,16 +97,6 @@ { struct ldapoptions *lo; - /* Get pointer to global option structure */ - lo = LDAP_INT_GLOBAL_OPT(); - if (NULL == lo) { - return LDAP_NO_MEMORY; - } - - if( lo->ldo_valid != LDAP_INITIALIZED ) { - ldap_int_initialize(lo, NULL); - } - if(ld != NULL) { assert( LDAP_VALID( ld ) ); @@ -117,6 +107,18 @@ lo = &ld->ld_options; } + if( lo == NULL ) { + /* Get pointer to global option structure */ + lo = LDAP_INT_GLOBAL_OPT(); + if (NULL == lo) { + return LDAP_NO_MEMORY; + } + + if( lo->ldo_valid != LDAP_INITIALIZED ) { + ldap_int_initialize(lo, NULL, NULL); + } + } + if(outvalue == NULL) { /* no place to get to */ return LDAP_OPT_ERROR; @@ -347,19 +349,35 @@ } int +ldap_set_option_in_context( + LDAPContext *context, + int option, + LDAP_CONST void *invalue) +{ + return ldap_set_option_2( context, NULL, option, invalue ); +} + +int ldap_set_option( LDAP *ld, int option, LDAP_CONST void *invalue) { - struct ldapoptions *lo; - int *dbglvl = NULL; + return ldap_set_option_2( NULL, ld, option, invalue ); +} - /* Get pointer to global option structure */ - lo = LDAP_INT_GLOBAL_OPT(); - if (lo == NULL) { - return LDAP_NO_MEMORY; - } +/* + * ldap_set_option_2: can set options per LDAP handle or per context. + * if handle is given, the context is ignored. + */ +int +ldap_set_option_2( + struct ldapoptions *lo, + LDAP *ld, + int option, + LDAP_CONST void *invalue) +{ + int *dbglvl = NULL; /* * The architecture to turn on debugging has a chicken and egg @@ -370,10 +388,6 @@ dbglvl = (int *) invalue; } - if( lo->ldo_valid != LDAP_INITIALIZED ) { - ldap_int_initialize(lo, dbglvl); - } - if(ld != NULL) { assert( LDAP_VALID( ld ) ); @@ -384,6 +398,17 @@ lo = &ld->ld_options; } + if( lo == NULL ) { + /* Get pointer to global option structure */ + lo = LDAP_INT_GLOBAL_OPT(); + if (lo == NULL) { + return LDAP_NO_MEMORY; + } + if( lo->ldo_valid != LDAP_INITIALIZED ) { + ldap_int_initialize(lo, dbglvl, NULL); + } + } + switch(option) { case LDAP_OPT_REFERRALS: if(invalue == LDAP_OPT_OFF) { @@ -668,7 +693,7 @@ default: #ifdef HAVE_TLS - if ( ldap_pvt_tls_set_option( ld, option, (void *)invalue ) == 0 ) + if ( ldap_pvt_tls_set_option_2( lo, ld, option, (void *)invalue ) == 0 ) return LDAP_OPT_SUCCESS; #endif #ifdef HAVE_CYRUS_SASL diff -Nru openldap-src/libraries/libldap/tls.c openldap-src-context/libraries/libldap/tls.c --- openldap-src/libraries/libldap/tls.c 2007-01-24 22:38:26.000000000 +0000 +++ openldap-src-context/libraries/libldap/tls.c 2007-02-17 13:22:45.000000000 +0000 @@ -1178,8 +1178,20 @@ } int +ldap_int_tls_config_in_context( struct ldapoptions *lo, int option, const char *arg ) +{ + return ldap_int_tls_config_2( lo, NULL, option, arg ); +} + +int ldap_int_tls_config( LDAP *ld, int option, const char *arg ) { + return ldap_int_tls_config_2( NULL, ld, option, arg ); +} + +int +ldap_int_tls_config_2( struct ldapconfig *lo, LDAP *ld, int option, const char *arg ) +{ int i; switch( option ) { @@ -1190,7 +1202,7 @@ case LDAP_OPT_X_TLS_RANDOM_FILE: case LDAP_OPT_X_TLS_CIPHER_SUITE: case LDAP_OPT_X_TLS_DHFILE: - return ldap_pvt_tls_set_option( ld, option, (void *) arg ); + return ldap_pvt_tls_set_option_2( lo, ld, option, (void *) arg ); case LDAP_OPT_X_TLS_REQUIRE_CERT: case LDAP_OPT_X_TLS: @@ -1216,7 +1228,7 @@ } if (i >= 0) { - return ldap_pvt_tls_set_option( ld, option, &i ); + return ldap_pvt_tls_set_option_2( lo, ld, option, &i ); } return -1; #ifdef HAVE_OPENSSL_CRL @@ -1230,7 +1242,7 @@ i = LDAP_OPT_X_TLS_CRL_ALL ; } if (i >= 0) { - return ldap_pvt_tls_set_option( ld, option, &i ); + return ldap_pvt_tls_set_option_2( lo, ld, option, &i ); } return -1; #endif @@ -1334,7 +1346,12 @@ int ldap_pvt_tls_set_option( LDAP *ld, int option, void *arg ) { - struct ldapoptions *lo; + return ldap_pvt_tls_set_option_2( NULL, ld, option, arg ); +} + +int +ldap_pvt_tls_set_option_2( struct ldapoptions *lo, LDAP *ld, int option, void *arg ) +{ if( ld != NULL ) { assert( LDAP_VALID( ld ) ); @@ -1345,7 +1362,8 @@ lo = &ld->ld_options; - } else { + } + if( lo == NULL ) { /* Get pointer to global option structure */ lo = LDAP_INT_GLOBAL_OPT(); if ( lo == NULL ) { --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nss_ldap.patch" This patch file is derived from PADL Software (nss_ldap). All of the modifications to PADL Software represented in the following patch(es) were developed by Timo Felbinger <timo(a)physik.uni-potsdam.de>. These modifications are not subject to any license of University of Potsdam. I, Timo Felbinger, hereby place the following modifications to PADL 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. diff -Nru nss_ldap-254/config.h.in nss_ldap-254-context/config.h.in --- nss_ldap-254/config.h.in 2006-12-18 08:12:56.000000000 +0000 +++ nss_ldap-254-context/config.h.in 2007-02-17 14:46:02.000000000 +0000 @@ -132,6 +132,9 @@ /* Define to 1 if you have the `ldap_initialize' function. */ #undef HAVE_LDAP_INITIALIZE +/* Define to 1 if you have the `ldap_create_context' function. */ +#undef HAVE_LDAP_CREATE_CONTEXT + /* Define to 1 if you have the `ldap_ld_free' function. */ #undef HAVE_LDAP_LD_FREE diff -Nru nss_ldap-254/configure nss_ldap-254-context/configure --- nss_ldap-254/configure 2006-12-18 08:12:56.000000000 +0000 +++ nss_ldap-254-context/configure 2007-02-17 14:46:37.000000000 +0000 @@ -1,4 +1,6 @@ #! /bin/sh +echo please run autoconf first! +exit 1 # Guess values for system-dependent variables and create Makefiles. # Generated automatically using autoconf version 2.13 diff -Nru nss_ldap-254/configure.in nss_ldap-254-context/configure.in --- nss_ldap-254/configure.in 2006-12-18 08:12:56.000000000 +0000 +++ nss_ldap-254-context/configure.in 2007-02-17 14:46:02.000000000 +0000 @@ -297,7 +297,7 @@ AC_CHECK_FUNCS(sasl_auxprop_request) AC_CHECK_FUNCS(ldap_init ldap_get_lderrno ldap_parse_result ldap_memfree ldap_controls_free) AC_CHECK_FUNCS(ldap_ld_free ldap_explode_rdn ldap_set_option ldap_get_option) -AC_CHECK_FUNCS(ldap_sasl_interactive_bind_s ldap_initialize ldap_search_ext) +AC_CHECK_FUNCS(ldap_sasl_interactive_bind_s ldap_initialize ldap_search_ext ldap_create_context) AC_CHECK_FUNCS(ldap_create_control ldap_create_page_control ldap_parse_page_control) if test "$enable_ssl" \!= "no"; then AC_CHECK_FUNCS(ldapssl_client_init ldap_start_tls_s ldap_pvt_tls_set_option ldap_start_tls) diff -Nru nss_ldap-254/ldap-nss.c nss_ldap-254-context/ldap-nss.c --- nss_ldap-254/ldap-nss.c 2006-12-18 08:12:56.000000000 +0000 +++ nss_ldap-254-context/ldap-nss.c 2007-02-17 14:46:02.000000000 +0000 @@ -137,7 +137,7 @@ /* * Global LDAP session. */ -static ldap_session_t __session = { NULL, NULL, 0, LS_UNINITIALIZED }; +static ldap_session_t __session = { NULL, NULL, NULL, 0, LS_UNINITIALIZED }; #if defined(HAVE_PTHREAD_ATFORK) || defined(HAVE_LIBC_LOCK_H) || defined(HAVE_BITS_LIBC_LOCK_H) static pthread_once_t __once = PTHREAD_ONCE_INIT; @@ -1003,7 +1003,7 @@ } static NSS_STATUS -do_init_session (LDAP ** ld, const char *uri, int defport) +do_init_session ( LDAPContext **ldap_context, LDAP ** ld, const char *uri, int defport) { int rc; int ldaps; @@ -1011,6 +1011,17 @@ char *p; NSS_STATUS stat; +#ifdef HAVE_LDAP_CREATE_CONTEXT + if( ! *ldap_context ) + { + /* make sure ldap config is read in a safe way */ + static const char *directives[2] = { "file=" NSS_LDAP_PATH_CONF, NULL }; + int rc = ldap_create_context( ldap_context, directives ); + if (rc != LDAP_SUCCESS) + return NSS_UNAVAIL; + } +#endif + ldaps = (strncasecmp (uri, "ldaps://", sizeof ("ldaps://") - 1) == 0); p = strchr (uri, ':'); /* we should be looking for the second instance to find the port number */ @@ -1028,7 +1039,11 @@ uri = uribuf; } +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_initialize_in_context (ld, uri, *ldap_context); +# else rc = ldap_initialize (ld, uri); +# endif #else if (strncasecmp (uri, "ldap://", sizeof ("ldap://") - 1) != 0) { @@ -1311,7 +1326,7 @@ assert (__session.ls_current_uri <= NSS_LDAP_CONFIG_URI_MAX); assert (cfg->ldc_uris[__session.ls_current_uri] != NULL); - stat = do_init_session (&__session.ls_conn, + stat = do_init_session ( &__session.ldap_context, &__session.ls_conn, cfg->ldc_uris[__session.ls_current_uri], cfg->ldc_port); if (stat != NSS_SUCCESS) diff -Nru nss_ldap-254/ldap-nss.h nss_ldap-254-context/ldap-nss.h --- nss_ldap-254/ldap-nss.h 2006-12-18 08:12:56.000000000 +0000 +++ nss_ldap-254-context/ldap-nss.h 2007-02-17 14:46:02.000000000 +0000 @@ -416,12 +416,19 @@ typedef enum ldap_session_state ldap_session_state_t; +/* for readability, make sure LDAPContext is at least a dummy type: */ +#ifndef HAVE_LDAP_CREATE_CONTEXT +# define LDAPContext void +#endif + /* * convenient wrapper around pointer into global config list, and a * connection to an LDAP server. */ struct ldap_session { + /* the context, if supported */ + LDAPContext *ldap_context; /* the connection */ LDAP *ls_conn; /* pointer into config table */ --pf9I7BMVVzbSWLtt Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pam_ldap.patch" This patch file is derived from PADL Software (pam_ldap). All of the modifications to PADL Software represented in the following patch(es) were developed by Timo Felbinger <timo(a)physik.uni-potsdam.de>. These modifications are not subject to any license of University of Potsdam. I, Timo Felbinger, hereby place the following modifications to PADL 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. diff -Nru pam_ldap-183/config.h.in pam_ldap-183-context/config.h.in --- pam_ldap-183/config.h.in 2006-10-19 13:22:27.000000000 +0000 +++ pam_ldap-183-context/config.h.in 2007-02-17 14:55:38.000000000 +0000 @@ -33,6 +33,9 @@ /* Define if you have the ldap_initialize function. */ #undef HAVE_LDAP_INITIALIZE +/* Define if you have the ldap_create_context function. */ +#undef HAVE_LDAP_CREATE_CONTEXT + /* Define if you have the ldap_memfree function. */ #undef HAVE_LDAP_MEMFREE diff -Nru pam_ldap-183/configure pam_ldap-183-context/configure --- pam_ldap-183/configure 2006-10-19 13:22:27.000000000 +0000 +++ pam_ldap-183-context/configure 2007-02-17 14:55:38.000000000 +0000 @@ -1,4 +1,6 @@ #! /bin/sh +echo Please run autoconf first! +exit 1 # Guess values for system-dependent variables and create Makefiles. # Generated automatically using autoconf version 2.13 diff -Nru pam_ldap-183/configure.in pam_ldap-183-context/configure.in --- pam_ldap-183/configure.in 2006-10-19 13:22:27.000000000 +0000 +++ pam_ldap-183-context/configure.in 2007-02-17 14:55:38.000000000 +0000 @@ -131,6 +131,7 @@ AC_CHECK_FUNCS(ldapssl_init ldap_start_tls_s ldap_pvt_tls_set_option) fi AC_CHECK_FUNCS(ldap_initialize) +AC_CHECK_FUNCS(ldap_create_context) AC_CHECK_FUNCS(ldap_sasl_bind ldap_sasl_interactive_bind_s) AC_CHECK_FUNCS(gethostbyname_r) diff -Nru pam_ldap-183/pam_ldap.c pam_ldap-183-context/pam_ldap.c --- pam_ldap-183/pam_ldap.c 2006-10-19 13:22:27.000000000 +0000 +++ pam_ldap-183-context/pam_ldap.c 2007-02-17 15:08:39.000000000 +0000 @@ -155,6 +155,11 @@ #endif static int pam_debug_level __UNUSED__ = 0; +#ifndef HAVE_LDAP_CREATE_CONTEXT +# typedef LDAPContext void; +#endif +static LDAPContext *ldap_context = 0; + #ifdef HAVE_LDAPSSL_INIT static int ssl_initialized = 0; #endif @@ -1190,6 +1195,36 @@ struct timeval tv; #endif +#ifdef HAVE_LDAP_CREATE_CONTEXT + /* make sure ldap config is read in a safe and transparent way */ + if( ! ldap_context ) + { + char *directives[2]; + int rc; + + if( session->conf->configFile == NULL ) + { + directives[0] = NULL; + } + else + { + directives[0] = malloc (strlen (session->conf->configFile) + 6); + if( directives[0] == NULL ) + return PAM_BUF_ERR; + strcpy( directives[0], "file=" ); + strcpy( directives[0]+5, session->conf->configFile ); + } + directives[1] = NULL; + rc = ldap_create_context( &ldap_context, directives ); + _pam_drop( directives[0] ); + if (rc != LDAP_SUCCESS || ! ldap_context ) + { + syslog (LOG_ERR, "pam_ldap: ldap_create_context: %s", ldap_err2string (rc)); + return PAM_SERVICE_ERR; + } + } +#endif + #ifdef HAVE_LDAP_SET_OPTION if (session->conf->debug) { @@ -1253,7 +1288,11 @@ #ifdef HAVE_LDAP_INITIALIZE if (session->conf->uri != NULL) { +# ifdef HAVE_LDAP_CREATE_CONTEXT + int rc = ldap_initialize_in_context (&session->ld, session->conf->uri, ldap_context); +# else int rc = ldap_initialize (&session->ld, session->conf->uri); +# endif if (rc != LDAP_SUCCESS) { syslog (LOG_ERR, "pam_ldap: ldap_initialize %s", @@ -1400,8 +1439,12 @@ /* rand file */ if (session->conf->tls_randfile != NULL) { - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_RANDOM_FILE, - session->conf->tls_randfile); +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_RANDOM_FILE, session->conf->tls_randfile); if (rc != LDAP_SUCCESS) { syslog (LOG_ERR, @@ -1415,7 +1458,12 @@ /* ca cert file */ if (session->conf->tls_cacertfile != NULL) { - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CACERTFILE, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_CACERTFILE, session->conf->tls_cacertfile); if (rc != LDAP_SUCCESS) { @@ -1429,7 +1477,12 @@ if (session->conf->tls_cacertdir != NULL) { /* ca cert directory */ - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CACERTDIR, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_CACERTDIR, session->conf->tls_cacertdir); if (rc != LDAP_SUCCESS) { @@ -1443,7 +1496,12 @@ if (session->conf->tls_checkpeer > -1) { /* require cert? */ - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_REQUIRE_CERT, &session->conf->tls_checkpeer); if (rc != LDAP_SUCCESS) { @@ -1457,7 +1515,12 @@ if (session->conf->tls_ciphers != NULL) { /* set cipher suite, certificate and private key: */ - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CIPHER_SUITE, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_CIPHER_SUITE, session->conf->tls_ciphers); if (rc != LDAP_SUCCESS) { @@ -1470,7 +1533,12 @@ if (session->conf->tls_cert != NULL) { - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_CERTFILE, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_CERTFILE, session->conf->tls_cert); if (rc != LDAP_SUCCESS) { @@ -1483,7 +1551,12 @@ if (session->conf->tls_key != NULL) { - rc = ldap_set_option (NULL, LDAP_OPT_X_TLS_KEYFILE, +# ifdef HAVE_LDAP_CREATE_CONTEXT + rc = ldap_set_option_in_context ( ldap_context, +# else + rc = ldap_set_option (NULL, +# endif + LDAP_OPT_X_TLS_KEYFILE, session->conf->tls_key); if (rc != LDAP_SUCCESS) { --pf9I7BMVVzbSWLtt--

1 0

(ITS#4845) Back-perl is non working
by kiwi＠oav.net 19 Feb '07

19 Feb '07

Full_Name: Xavier Beaudouin Version: 2.3.33 OS: FreeBSD 6.2 URL: http://www.oav.net/tmp/openldap/ Submission from: (NULL) (82.225.248.92) Seems since 2.3 branch back-perl doesn't work files in http://www.oav.net/tmp/openldap/ works correctly on 2.2.xx branch but seems to returns nothing. Debug output : # /usr/local/libexec/slapd -d 4 -f /usr/local/etc/openldap/slapd.conf @(#) $OpenLDAP: slapd 2.3.33 (Feb 19 2007 23:24:47) $ root@diskless.home.oav.net:/usr/ports/net/openldap23-server/work/openldap-2.3.33/servers/slapd daemon_init: <null> => ldap_bv2dn(ou=mailboxes,dc=kazar,dc=net,0) <= ldap_bv2dn(ou=mailboxes,dc=kazar,dc=net)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=mailboxes,dc=kazar,dc=net)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=mailboxes,dc=kazar,dc=net)=0 Starting mailboxes => ldap_bv2dn(cn=Subschema,0) <= ldap_bv2dn(cn=Subschema)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=subschema)=0 WARNING: No dynamic config support for database perl. slapd starting connection_get(8) send_ldap_result: err=0 matched="" text="" connection_get(8) => ldap_bv2dn(ou=mailboxes,dc=kazar,dc=net,0) <= ldap_bv2dn(ou=mailboxes,dc=kazar,dc=net)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=mailboxes,dc=kazar,dc=net)=0 => ldap_dn2bv(272) <= ldap_dn2bv(ou=mailboxes,dc=kazar,dc=net)=0 SRCH "ou=mailboxes,dc=kazar,dc=net" 2 0 0 0 0 filter: (uid=kiwi(a)oav.net) attrs: We get a request for UID Looking for : (uid=kiwi(a)oav.net) We get some results... Sending -> dn : uid=kiwi(a)oav.net,ou=mailboxes,dc=kazar,dc=net objectClass : top objectClass : kazarPerson uid : kiwi(a)oav.net cn : Nom Prenom description : Sample description uidNumber : 10 gidNumber : 10 userPassword : Password homeDirectory : /home/test mailQuota : 50 CouriermailQuota : 50S str2entry: entry -1 has no dn str2entry(dn) failed send_ldap_result: err=0 matched="" text="" connection_get(8) To the query : # ldapsearch -h 127.0.0.1 -b ou=mailboxes,dc=kazar,dc=net uid=kiwi(a)oav.net # extended LDIF # # LDAPv3 # base <ou=mailboxes,dc=kazar,dc=net> with scope subtree # filter: uid=kiwi(a)oav.net # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 Seems that str2entry from search.c doesn't get any value. Is that because internals of OpenLDAP has changed ? Thanks /Xavier

1 0

Re: (ITS#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 19 Feb '07

19 Feb '07

<quote who="hyc(a)symas.com"> > ghenry(a)suretecsystems.com wrote: >> In another step towards 100% remote admin/config, could we store >> StartTLS >> certs in the directory for slapd usage, replacing the need for: >> >> TLS* config path hardcoding.? > > One step at a time... Sure, I just wanted to have this wish recorded somewhere ;-) > Ordinarily I would store certs in an entry with the > same DN as the cert. This would mean creating a directory entry for your > server name, as well as directory entries for any client certs you wanted > to > use. That's probably not the ideal way to go here. > > We could store the certs directly, in attributes under cn=config. We could > also just store DNs in the config attributes, pointing to certs in some > other > database entries. Understood. > > -- > -- Howard Chu > Chief Architect, 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#4829) slapd-config should create olcDbDirectory
by hyc＠symas.com 19 Feb '07

19 Feb '07

ghenry(a)suretecsystems.com wrote: > In another step towards 100% remote admin/config, could we store StartTLS > certs in the directory for slapd usage, replacing the need for: > > TLS* config path hardcoding.? One step at a time... Ordinarily I would store certs in an entry with the same DN as the cert. This would mean creating a directory entry for your server name, as well as directory entries for any client certs you wanted to use. That's probably not the ideal way to go here. We could store the certs directly, in attributes under cn=config. We could also just store DNs in the config attributes, pointing to certs in some other database entries. -- -- Howard Chu Chief Architect, 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#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 18 Feb '07

18 Feb '07

<quote who="ghenry(a)suretecsystems.com"> > <quote who="Howard Chu"> >> ghenry(a)suretecsystems.com wrote: >> >>> Dear All, >>> >>> If we are to suppose that slapd-config is to provide 100% remote >>> configuration, >>> then directories should be created as set in: >>> >>> olcDbDirectory >>> set_lg_dir >>> >>> >>> Questions/Needs: >>> >>> 1. How to handle existing directories on mkdir? >>> 2. Some global cn=config setting to say what cn=config is allowed to do >>> 3. Plus many more I'm sure. >> >> Some of this touches on issues raised in ITS#4535. We probably need to >> answer >> those points first. > > Understood. > In another step towards 100% remote admin/config, could we store StartTLS certs in the directory for slapd usage, replacing the need for: TLS* config path hardcoding.? Gavin.

1 0

(ITS#4844) Missing 2.4 man pages and things marked as "Experimental"
by ghenry＠suretecsystems.com 17 Feb '07

17 Feb '07

Full_Name: Gavin Henry Version: 2.3.34/2.4.4alpha OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Just a quick to note that there are some overlays missing from slapd.overlays.5 in 2.4.4alpha and actual man pages. Also, relay and rwm are still marked as experimental in some places. grep experimental doc/man/man5/* doc/man/man5/slapd-relay.5:This backend and the above mentioned overlay are experimental. doc/man/man5/slapo-rwm.5:This overlay is experimental. I'll help where I can, Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 17 Feb '07

17 Feb '07

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: > >> Dear All, >> >> If we are to suppose that slapd-config is to provide 100% remote >> configuration, >> then directories should be created as set in: >> >> olcDbDirectory >> set_lg_dir >> >> >> Questions/Needs: >> >> 1. How to handle existing directories on mkdir? >> 2. Some global cn=config setting to say what cn=config is allowed to do >> 3. Plus many more I'm sure. > > Some of this touches on issues raised in ITS#4535. We probably need to > answer > those points first. Understood. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > Chief Architect, OpenLDAP http://www.openldap.org/project/ >

1 0

ITS#4535 back-config can allow break-ins
by hyc＠symas.com 17 Feb '07

17 Feb '07

The first issue here was in regards to protection for the config backend when running the tests in the test suite. That was addressed mainly by using a randomly generated rootpw for cn=config in all of the tests. Also the default ACL for the config backend is explicitly set to "access to * by * none". In terms of the potential attacks on a server through back-config - it's obvious to me that you have to treat access to back-config the same as you would treat SSH credentials for a root user on the machine. That was one of the main reasons I decided to make cn=config only usable by its rootdn in 2.3. But since you really should be able to delegate authority, we added regular ACL support for 2.4. So it still comes down to having sane ACLs configured. Most of the attacks listed here require a user to have shell access to the machine, and write access to relevant filesystems. Frankly I think these attack scenarios are contrived - if you have untrusted users logging in to your system, you have other problems already. re: a meta-config file - No. The design goal here is to remove all limitations that prevent totally remote administration of the server, not add new ones. Artificial restrictions, just like artificially restricting 2.3 to rootdn only, will only impair usability and eventually get removed. re: lstat/fstat to prevent use of symlinks - No. There are too many valid uses for symlinks. What might make sense would be to fstat targets and check that they are owned by the current user and are not world-writable. We might also include root-owned directories that are world-writable with the sticky bit set. re: Documentation - sure. re: slaptools with -r/-u/-g - That's been discussed in ITS#4719. The consensus there seems (to me) to be that people with root access better know wth they're doing. re: adding dangerous database configurations - this raises a question about the config DIT. It implies a need for individual containers for backends, databases, and modules, so that you can configure write access to their children attribute. Otherwise, at the moment, we have no way to give fine grained access as to who can create what entries. The other alternative is to make back-config's add handler check for wadd access to the objectclass attribute of new entries, which would be oddly inconsistent with regular backend behavior. I specifically omitted such containers in the original DIT because I assumed only a rootDN, and with the object types essentially coded into their RDNs, the containers were superfluous. I still consider such containers redundant, and would lean toward the objectclass ACL check, which we can also make value-dependent to control exactly what types of databases an administrator can add. Assuming we have fine-grain control over what databases can be added, there should be no further consideration of whether to allow back-passwd, back-perl, or whatever. If an authorized admin wants to add them, let them. Fine-grained restriction of modules is pretty much irrelevant - all we have to go on is a name, which need not bear any relation to the module's actual content. The best we can do here is check ownership, as with other path-related items. re: Can one add "some-attribute:< file:///foobar" over the protocol to a back-ldif database to read file /foobar? I don't think so, but...? No. The URL is processed by the LDIF reader, which in this case is the client. At this point we should probably split this ITS into a few different ones. The main point, vulnerability in the test suite, has already been addressed. The doc-related issues obviously should go to a Doc bug. That leaves path ownership/permission checking for one bug, and fine-grained control of Adds as a separate bug. -- -- Howard Chu Chief Architect, 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#4829) slapd-config should create olcDbDirectory
by hyc＠symas.com 17 Feb '07

17 Feb '07

ghenry(a)suretecsystems.com wrote: > Dear All, > > If we are to suppose that slapd-config is to provide 100% remote configuration, > then directories should be created as set in: > > olcDbDirectory > set_lg_dir > > > Questions/Needs: > > 1. How to handle existing directories on mkdir? > 2. Some global cn=config setting to say what cn=config is allowed to do > 3. Plus many more I'm sure. Some of this touches on issues raised in ITS#4535. We probably need to answer those points first. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Leaks from test050 in re24
by Pierangelo Masarati 15 Feb '07

15 Feb '07

I see some small leaks in test050; I'm posting valgrind's output below, unfortunately I have no time to investigate them right now. p. ==23984== 71,251 (5,744 direct, 65,507 indirect) bytes in 153 blocks are definitely lost in loss record 7 of 8 ==23984== at 0x4004405: malloc (vg_replace_malloc.c:149) ==23984== by 0x821A75F: ber_memalloc_x (memory.c:226) ==23984== by 0x821A879: ber_memrealloc_x (memory.c:307) ==23984== by 0x821B178: ber_bvreplace_x (memory.c:706) ==23984== by 0x80F5734: slap_queue_csn (ctxcsn.c:168) ==23984== by 0x80F582D: slap_get_csn (ctxcsn.c:191) ==23984== by 0x8088AE3: slap_add_opattrs (add.c:601) ==23984== by 0x8123546: ldif_back_add (ldif.c:799) ==23984== by 0x806C426: config_setup_ldif (bconfig.c:3495) ==23984== by 0x806C7CD: read_config (bconfig.c:3573) ==23984== by 0x80622ED: main (main.c:747) ==23984== 65,507 bytes in 497 blocks are indirectly lost in loss record 8 of 8 ==23984== at 0x4004405: malloc (vg_replace_malloc.c:149) ==23984== by 0x821A75F: ber_memalloc_x (memory.c:226) ==23984== by 0x821ABD7: ber_dupbv_x (memory.c:504) ==23984== by 0x80C5A80: objectClassPretty (schema_prep.c:100) ==23984== by 0x80A09D6: ordered_value_pretty (value.c:496) ==23984== by 0x809BACA: slap_mods_check (modify.c:577) ==23984== by 0x8087AD0: do_add (add.c:160) ==23984== by 0x807F866: connection_operation (connection.c:1129) ==23984== by 0x807FD33: connection_read_thread (connection.c:1257) ==23984== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==23984== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==23984== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so) ==24033== 183 (60 direct, 123 indirect) bytes in 6 blocks are definitely lost in loss record 5 of 7 ==24033== at 0x4004405: malloc (vg_replace_malloc.c:149) ==24033== by 0x821A75F: ber_memalloc_x (memory.c:226) ==24033== by 0x821A7B2: ber_memalloc (memory.c:242) ==24033== by 0x809FB6C: value_add_one (value.c:96) ==24033== by 0x80F5EFC: slap_parse_sync_cookie (ldapsync.c:238) ==24033== by 0x81CD1EA: syncprov_parseCtrl (syncprov.c:2768) ==24033== by 0x80B7266: slap_parse_ctrl (controls.c:580) ==24033== by 0x80B7A0D: get_ctrls (controls.c:749) ==24033== by 0x80822C2: do_search (search.c:165) ==24033== by 0x807F866: connection_operation (connection.c:1129) ==24033== by 0x807FD33: connection_read_thread (connection.c:1257) ==24033== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==24033== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==24033== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so) ==24000== 70,778 (5,176 direct, 65,602 indirect) bytes in 142 blocks are definitely lost in loss record 8 of 9 ==24000== at 0x40056BF: calloc (vg_replace_malloc.c:279) ==24000== by 0x821A7F0: ber_memcalloc_x (memory.c:280) ==24000== by 0x809F775: ch_calloc (ch_malloc.c:104) ==24000== by 0x8088695: slap_mods2entry (add.c:472) ==24000== by 0x80E8A14: syncrepl_message_to_entry (syncrepl.c:1723) ==24000== by 0x80E5840: do_syncrep2 (syncrepl.c:790) ==24000== by 0x80E6C23: do_syncrepl (syncrepl.c:1164) ==24000== by 0x807FD51: connection_read_thread (connection.c:1259) ==24000== by 0x81E7F23: ldap_int_thread_pool_wrapper (tpool.c:704) ==24000== by 0x692370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==24000== by 0x475FFD: clone (in /lib/tls/libc-2.3.4.so)

1 0

Re: (ITS#4420) Hanging CLOSE_WAIT connections in ldap-backend
by aar＠cpan.org 15 Feb '07

15 Feb '07

I'm experiencing the CLOSE_WAIT problem with slapd 2.3.32 on MacOS X (PPC). Cached connections aren't being leaked but they aren't closed on idle-timeout and they remain in CLOSE_WAIT state after the remote host has gone. Compile options: ./configure --enable-rewrite --enable-ldap --enable-meta --enable-proxycache --enable-spasswd slapd.conf: =========== database ldap suffix "dc=AddressBooks,dc=example,dc=com" uri ldap://localhost:8080 idle-timeout 2 idassert-bind bindmethod=none binddn="cn=Administrative Identity,dc=sssss" credentials="admin_password" authzID="dn:cn=Sandbox,dc=local,dc=example,dc=com" mode=self authz=proxyAuthz (The problem appears also without idle-timeout.) Steps to reproduce: 1. start slapd 2. connect to slapd and do some queries 3. disconnect the proxied server (for example by killing it) 4. netstat -a still shows the connection as CLOSE_WAIT Debug: when running slapd with "-d 5", nothing is printed when the connection is closed by the remote host (i.e. when I kill it), so slapd isn't probably catching the event at all. - alessandro ranellucci.

1 0

Re: (ITS#4830) test030-relay fails with back-meta
by hyc＠symas.com 14 Feb '07

14 Feb '07

ahasenack(a)terra.com.br wrote: > On Fri, Feb 02, 2007 at 04:03:43PM +0000, ahasenack(a)terra.com.br wrote: >> ==> rewrite_context_apply [depth=1] string='(objectClass=*)' >> ==> rewrite_context_apply [depth=1] res={0,'NULL'} >> [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" >> /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: >> symbol lookup error: >> +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: >> ldap_back_proxy_authz_ctrl > > Howard debugged this on IRC and it turns out that our (mine and > _ranger_'s) libunixodbc has lt_dl* symbols in it. Relinking slapd > without the unixodbc lib fixes it. Yes, so there are two potential issues - the unixodbc shared library seems to be statically linked with an older version of libltdl. I didn't run into this problem on my build because I don't have that odbc library. Anyway, due to the link order of the libraries, the lt_dlopen in this library gets used before the linker resolves to the system's libltdl.so, and it seems that this version of lt_dlopen doesn't automatically export the symbols of modules that it loads. I'm guessing the reason this is a problem in 2.3.33 and not in 2.3.32 is because there is a new dependency in 2.3.33 between back-meta and back-ldap. The other part of this is that the slapd binary should not be getting linked against -lodbc when back_sql is built as a module. Although, if back-sql is built statically, and other backends are dynamic, this problem may still crop up. It seems that fixing -lodbc would be required then. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs