openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#8167) The new non-blocking TLS connect does not work in a reference/referral
by ipuleston＠sonicwall.com 09 Jun '15

09 Jun '15

Full_Name: Ian Puleston Version: 2.4.40 OS: VxWorks URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.118.31.3) I've been using the new non-blocking TLS connect feature added in version 2.4.34 (issue #7428, compiled with LDAP_USE_NON_BLOCKING_TLS) and found a problem that it does not work in a reference/referral. It only works on the default connection, and that can cause a long or permanent hang in SSL_connect as follows, even when a network timeout is set and LDAP_USE_NON_BLOCKING_TLS is on: ldap_result -> ldap_chase_v3referrals ldap_chase_v3referrals -> ldap_send_server_request ldap_send_server_request -> ldap_new_connection ldap_new_connection -> ldap_int_open_connection ldap_int_open_connection -> ldap_int_tls_start ldap_int_tls_start -> ldap_pvt_tls_connect ldap_pvt_tls_connect -> (v0) tlso_session_connect -> SSL_connect The problem is that the calls to ber_sockbuf_ctrl with LBER_SB_OPT_SET_NONBLOCK pass the Sockbuf as ld->ld_sb where they should be passing it as sb, that being the Sockbuf for this connection. The following 3 changes in ldap_int_tls_start fix it: Change: ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, sb ); to: ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); Change: ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, sb ); to: ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 ); Change: ber_sockbuf_ctrl( ld->ld_sb, LBER_SB_OPT_SET_NONBLOCK, NULL ); to: ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, NULL )B3B Note I also changed the 3rd argument there from "sb" to "(void*)1" just because I think passing sb there is a little confusing. Either will work fine. Ian

1 0

(ITS#8166) translucent overlay - compatibility with other overlays that need write access
by thomcz＠gmail.com 08 Jun '15

08 Jun '15

Full_Name: Thomas Keil Version: 2.4.40 OS: Debian 8.0 Jessie URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (139.30.84.202) This is a software enhancement request. I have the following use case at hand: My university provides a central LDAP directory which authenticates users but does not contain group information. For my institute we want to set up our own OpenLDAP server which relays the user authentication to the central directory (via back_ldap) but additionally provides group information. This should be used by a network of linux machines for user authentication, group management and login filtering. For reasons of high availability we want to replicate our local LDAP server using the builtin replication mechanism of OpenLDAP. This seems to be a nice example for the use of the translucent backend. Nevertheless group membership (for login filtering) can only be provided using the memberof overlay which (so it seems) is not compatible with the translucent overlay. Furthermore the syncprov overlay needs to access the lastmod attribute which is disabled for databases using the translucent overlay. Thus a local database combined with the translucent overlay cannot be replicated at all. To me it seems that these problems can be solved by allowing write access to the local database for other overlays when used in combination with the translucent overlay. It would make this overlay much more useful than it is right now since it would allow to use this in large scale deployments as well (where replication is essential). This is valid especially for cases where the local administration has no write access to the central directory.

1 0

(ITS#8165) Add proper versioning to liblmdb
by quanah＠openldap.org 05 Jun '15

05 Jun '15

Full_Name: Quanah Gibson-Mount Version: HEAD OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) LMDB has matured to the point at which it should be creating a properly versioned library for linking. Currently, only liblmdb.so is created. It would be preferable to see it in libtool format (liblmdb.so.x.y.z). Should be done for the 0.9.15 release.

1 0

Re: (ITS#8164) RFC slapo-unique: set matchedDN
by pierangelo.masarati＠polimi.it 05 Jun '15

05 Jun '15

On 05/06/2015 17:41, michael(a)stroeder.com wrote: > Full_Name: Michael Str.der > Version: HEAD > OS: > URL: > Submission from: (NULL) (212.227.35.94) > > > It would be handy if slapo-unique could set matchedDN along with result code > constraintViolation(19) to a DN of an existing entry causing the constraint to > fail. I think this would violate the purpose and specification of matchedDN. It would be more appropriate to have that piece of info returned within the control value of a specifically designed response control, when the control is explicitly requested. What you're asking for could perhaps be logged, if it isn't yet. My 2c. Ciao, p. > > To avoid information disclosure ACL checking could be performed to determine > whether the bound identity has at least search privilege on the entry pseudo > attr and unique attr. > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#8164) RFC slapo-unique: set matchedDN
by michael＠stroeder.com 05 Jun '15

05 Jun '15

Full_Name: Michael Str.der Version: HEAD OS: URL: Submission from: (NULL) (212.227.35.94) It would be handy if slapo-unique could set matchedDN along with result code constraintViolation(19) to a DN of an existing entry causing the constraint to fail. To avoid information disclosure ACL checking could be performed to determine whether the bound identity has at least search privilege on the entry pseudo attr and unique attr.

1 0

Re: (ITS#8158) cldap broken for aix and solaris
by h.b.furuseth＠usit.uio.no 05 Jun '15

05 Jun '15

On 05. juni 2015 08:59, goran.hammarback(a)foxt.com wrote: > Yeah, the fallback... I really did not know what to use there. I knew > sizeof(struct sockaddr_storage) would work on Linux but most likely not > on Solaris and AIX, so I used sizeof(struct sockaddr). Unfortunately I > have no way of testing if that really works at all for any platform so I > guess your way is probably better... Aha! Yes, then it should be sockaddr_storage. sockaddr breaks for any address type which is bigger than sizeof(struct sockaddr), which can be small. sockaddr_storage only breaks on an OS which complains when it is too big for the specified address type. -- Hallvard

1 0

Re: (ITS#8158) cldap broken for aix and solaris
by goran.hammarback＠foxt.com 05 Jun '15

05 Jun '15

On tor, 2015-06-04 at 23:06 +0200, Hallvard Breien Furuseth wrote: > On 03/06/15 08:47, goran.hammarback(a)foxt.com wrote: > > Hmm, my fingers thought it was still february. Now I have uploaded a > > file with the correct name, goran-hammarback-150603.ext. > > The date is probably just for disambiguation anyway. > > Tweaked it a bit, I expect it should look like this: > ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150604.diff > > Is there a reason you switched to sizeof(struct sockaddr) from > sockaddr_storage as the fallback? Otherwise sockaddr_storage > seems better, since that has presumably worked on most hosts. > Should only matter if people play tricks like using ldap_init_fd() > to create an unsupported connection type, e.g. "UDP ldapi://". Yeah, the fallback... I really did not know what to use there. I knew sizeof(struct sockaddr_storage) would work on Linux but most likely not on Solaris and AIX, so I used sizeof(struct sockaddr). Unfortunately I have no way of testing if that really works at all for any platform so I guess your way is probably better... > > Anyway, please test (or protest if it should be sockaddr). > The change from your patch may be trivial, but that doesn't > mean I couldn't have managed to break it:-) > > Note that OpenLDAP should be edited with editor tab width = > indentation = 4. Though some code has been written with > tab width = 8, so it looks messy either way. > Your patch looks fine. I will not have time to test it until next week earliest. My patch was meant only as an example, so I did not really think about indentation. Regards, /Göran

1 0

Re: (ITS#8158) cldap broken for aix and solaris
by h.b.furuseth＠usit.uio.no 04 Jun '15

04 Jun '15

On 03/06/15 08:47, goran.hammarback(a)foxt.com wrote: > Hmm, my fingers thought it was still february. Now I have uploaded a > file with the correct name, goran-hammarback-150603.ext. The date is probably just for disambiguation anyway. Tweaked it a bit, I expect it should look like this: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150604.diff Is there a reason you switched to sizeof(struct sockaddr) from sockaddr_storage as the fallback? Otherwise sockaddr_storage seems better, since that has presumably worked on most hosts. Should only matter if people play tricks like using ldap_init_fd() to create an unsupported connection type, e.g. "UDP ldapi://". Anyway, please test (or protest if it should be sockaddr). The change from your patch may be trivial, but that doesn't mean I couldn't have managed to break it:-) Note that OpenLDAP should be edited with editor tab width = indentation = 4. Though some code has been written with tab width = 8, so it looks messy either way. -- Hallvard

1 0

Re: (ITS#8163) Broken handling of deprecated attributes
by michael＠stroeder.com 03 Jun '15

03 Jun '15

pierre(a)reactos.org wrote: > It seems that the SQL backend is indeed responsible for this and > apparently makes OpenLDAP no longer RFC-compliant. Simply don't use back-sql. And next time please provide exact config information. Ciao, Michael.

1 0

Re: (ITS#8163) Broken handling of deprecated attributes
by pierre＠reactos.org 03 Jun '15

03 Jun '15

This is a cryptographically signed message in MIME format. --------------ms010206060101070502000609 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/03/2015 03:52 PM, Howard Chu wrote: > pierre(a)reactos.org wrote: >> This is a cryptographically signed message in MIME format. >> >> --------------ms070202050304000100090907 >> Content-Type: text/plain; charset=3Dwindows-1252 >> Content-Transfer-Encoding: quoted-printable >> >> Finally, some more information thanks to the testing env. >> >> It seems that the SQL backend is indeed responsible for this and >> apparently makes OpenLDAP no longer RFC-compliant. >=20 > back-sql currently has no maintainer and is not recommended for use. > The primary database backends are back-bdb,hdb, and mdb. All of these > are RFC-compliant. Unfortunately, these backends are not matching our use-case... I'll try to see whether I can (hack)fix it, even though, I'm not used to LDAP nor to OpenLDAP. And regarding my previous mail, the failing call is actually the call to structural_class() at line 1057 of entry-id. --=20 Pierre Schweitzer <pierre(a)reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V. --------------ms010206060101070502000609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMnTCC BjQwggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDI1NVoXDTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOM KqANy9BV7V0igWdGxA8IU77L3aTxErQ+fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi 8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8M DP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHksw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y 2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHHtOkzUreG//CsFnB9+uaYSlR65cdG zTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd+q9rMfPIHeOsuzAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqp Jw3I07QWke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Mic c/NXcs7kPBRdn6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9Jphw UPTXwHovjavRnhUQHLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMc p+reg9901zkyT3fDW/ivJVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT +HBDYtbuvexNftwNQKD5193A7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1X hwby6mLhkbaXslkVtwEWT3Van49rKjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvO hNz/QplNa+VkIsrcp7+8ZhP1l1b2U6MaxIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC 0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqh AChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H75dVCV33K6FuxZrf09yTz+Vx/PkdRUYk XmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGYTCCBUmgAwIBAgICWQwwDQYJKoZIhvcNAQEL BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xNDExMjQxNjI3Mjda Fw0xNjExMjQyMDIyMjZaMH4xCzAJBgNVBAYTAkZSMRgwFgYDVQQIEw9IYXV0ZS1Ob3JtYW5k aWUxFjAUBgNVBAcTDU1vbnRpdmlsbGllcnMxGjAYBgNVBAMTEVBpZXJyZSBTY2h3ZWl0emVy MSEwHwYJKoZIhvcNAQkBFhJwaWVycmVAcmVhY3Rvcy5vcmcwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC8SYZrOQ1QDv1kIOpgVq/b7szSPKslgvoWds2XORWlmr1sunnT6rh/ dS49XLFIfvqBtjZJfszA5ISFiI0jvp1kWqM+/DRvTZ+IRVyMtPaRjeAnvuXcjn/ARLzgX41l Ud1Nvhr3xVUaBczz+PBrYpSiL33q8PWBlmPUB/aFCfiOshZUncf6Oyp6htM/wGYLBYPeYe/N f/H22oA47gecS5Wklywa7mBdsLzDOkWM+4vtxPUSNcup1wsR/uQiYOLEC6NgjoUH+Io9p5oR RrTYDjd3sLT+bhLAzBpwkMBa0MlIufzyxMSB2pJO0wj1itVbKORU0ms4lMBiOvpJNxMrS93J AgMBAAGjggLYMIIC1DAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFBhmqkwsm1WisdrKJVqDH/Xhvm32MB8GA1UdIwQY MBaAFK5Vg2/sMcq59x36r2sx88gd46y7MB0GA1UdEQQWMBSBEnBpZXJyZUByZWFjdG9zLm9y ZzCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0 ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxpZGF0aW9uIHJlcXVp cmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0 aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5 IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNv bS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0 dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAj BgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQELBQADggEB ACbcmhzJrkldFMDb4Qb1WXVnDtVJBNJjR/AzTZxc+8r/9UAdxfI4SlYbEXU9cZ/r2JaRXPeh 5A3FEaUOBafRkSwKYfw8XXIIe0q0S8tDJ+uigHChf9HR4YqhqhC+1pfO15YnlyEcRXe5xmHt lNUyKrVqPEzPus/58i2dprOk2TJpoy3jPkg9Z/S31F9+ipojV7aOkOaEUn+GxAPVRhmbEWqr c0Vnu45vvgVgXI4TwDCVp7lS9Rl/X/ytEunbC/AXAO4eEDLkkYxMTe8xkbLt39da5nqc0ta+ fsAecskmU8Jg38Xh2Kj5K+3MeKhZFyiLNdr4YKYJuVDFoZ8SWwIROBIxggPaMIID1gIBATCB kzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJZDDAJBgUrDgMCGgUAoIIC GzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA2MDMxNDUw MzZaMCMGCSqGSIb3DQEJBDEWBBSRFGOtquxUAEeY2pce3+qkyzZ+mTBsBgkqhkiG9w0BCQ8x XzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwIC AgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGkBgkrBgEEAYI3 EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICWQwwgaYGCyqG SIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAlkM MA0GCSqGSIb3DQEBAQUABIIBAAQyivx/2JJNvDy+ZH7mOs64BaztLIKVASx0NfEKCSI9oYgC JAhUTCnNAH++THUb8XcF7G9IG7jdqBLXjajuNtbpoCx/sryAGK+Mtjy+IH4hrhICS/U/rSFt mClSvauMWjCQIRSUjBH43Otasl2nYoMKznYHd9geeFfZI2QYN3hNf0q60GEHoYbG/YMDj3Fy iJ9SLbCjCcfYdwdBR+JvJWneuv5fYdViE9bUPbyBLy/6EO/hmN7dvXNyn5DnffiSsIuANyYH 4sScAoXLpfBqVjnWVmb2PjaOJ8l/SxBC1jECdgWZe63oNJN/2eYEdOLFRpEuOIf2/LKDofEQ Mrj/LLsAAAAAAAA= --------------ms010206060101070502000609--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs