openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8533) Support OpenSSL-1.1.0c
by hyc＠symas.com 05 Apr '17

05 Apr '17

quanah(a)symas.com wrote: > --On Wednesday, April 05, 2017 11:12 PM +0000 quanah(a)symas.com wrote: > >>> The following 5 function calls are problematic: >>> >>> ./.libs/libldap.so: undefined reference to `OpenSSL_add_all_digests' >>> ./.libs/libldap.so: undefined reference to `SSL_load_error_strings' >>> ./.libs/libldap.so: undefined reference to `ERR_free_strings' >>> ./.libs/libldap.so: undefined reference to `EVP_cleanup' >>> ./.libs/libldap.so: undefined reference to `SSL_library_init' > > The above can be fixed with the following patch: > > build@u12build:~/git/symas-packages/thirdparty/openldap/build/UBUNTU12_64/symas-openldap/libraries/libldap$ > diff -u tls_o.c.orig tls_o.c > --- tls_o.c.orig 2017-04-05 14:40:02.849559862 -0700 > +++ tls_o.c 2017-04-05 15:13:09.371718493 -0700 > @@ -154,9 +154,16 @@ > (void) tlso_seed_PRNG( lo->ldo_tls_randfile ); > #endif > > +#if OPENSSL_VERSION_NUMBER < 0x10100000 Are you sure about exactly when these functions were removed? The title of this ITS is for 1.1.0c, and the earlier patches were for 1.1.0a. For version 1.1.0c we should be comparing to 0x1010003f, not 0x10100000. > SSL_load_error_strings(); > SSL_library_init(); > OpenSSL_add_all_digests(); > +#else > + OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS \ > + | OPENSSL_INIT_LOAD_CRYPTO_STRINGS, NULL); > + OPENSSL_init_ssl(0, NULL); > + OPENSSL_init_crypto(OPENSSL_INIT_ADD_ALL_DIGESTS, NULL); > +#endif > > /* FIXME: mod_ssl does this */ > X509V3_add_standard_extensions(); > @@ -172,6 +179,7 @@ > { > struct ldapoptions *lo = LDAP_INT_GLOBAL_OPT(); > > +#if OPENSSL_VERSION_NUMBER < 0x10100000 > EVP_cleanup(); > #if OPENSSL_VERSION_NUMBER < 0x10000000 > ERR_remove_state(0); > @@ -179,6 +187,9 @@ > ERR_remove_thread_state(NULL); > #endif > ERR_free_strings(); > +#else > + ERR_remove_thread_state(NULL); > +#endif > > if ( lo->ldo_tls_randfile ) { > LDAP_FREE( lo->ldo_tls_randfile ); > > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by hyc＠symas.com 05 Apr '17

05 Apr '17

quanah(a)symas.com wrote: > --On Wednesday, April 05, 2017 10:38 PM +0000 quanah(a)symas.com wrote: > >> --On Wednesday, April 05, 2017 7:58 PM +0000 quanah(a)symas.com wrote: >> >>> If openssl 1.1.0 is built with the option "no-deprecated" the build will >>> fail, as portions of the code still use the pre 1.1 API. This needs >>> fixing before release. >> >> The following 5 function calls are problematic: >> >> ./.libs/libldap.so: undefined reference to `OpenSSL_add_all_digests' >> ./.libs/libldap.so: undefined reference to `SSL_load_error_strings' >> ./.libs/libldap.so: undefined reference to `ERR_free_strings' >> ./.libs/libldap.so: undefined reference to `EVP_cleanup' >> ./.libs/libldap.so: undefined reference to `SSL_library_init' >> >> >> Looking at the best way in which to fix. > > These also need fixing, as they don't exist in 1.1 when the old API is > disabled. > > CRYPTO_num_locks() > CRYPTO_LOCK > CRYPTO_set_locking_callback() > CRYPTO_set_id_callback() These only exist because OpenSSL's support for threading was mostly nonexistent in the past. They should just be #ifdef'd away for 1.1. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 05 Apr '17

05 Apr '17

--On Wednesday, April 05, 2017 11:12 PM +0000 quanah(a)symas.com wrote: >> The following 5 function calls are problematic: >> >> ./.libs/libldap.so: undefined reference to `OpenSSL_add_all_digests' >> ./.libs/libldap.so: undefined reference to `SSL_load_error_strings' >> ./.libs/libldap.so: undefined reference to `ERR_free_strings' >> ./.libs/libldap.so: undefined reference to `EVP_cleanup' >> ./.libs/libldap.so: undefined reference to `SSL_library_init' The above can be fixed with the following patch: build@u12build:~/git/symas-packages/thirdparty/openldap/build/UBUNTU12_64/symas-openldap/libraries/libldap$ diff -u tls_o.c.orig tls_o.c --- tls_o.c.orig 2017-04-05 14:40:02.849559862 -0700 +++ tls_o.c 2017-04-05 15:13:09.371718493 -0700 @@ -154,9 +154,16 @@ (void) tlso_seed_PRNG( lo->ldo_tls_randfile ); #endif +#if OPENSSL_VERSION_NUMBER < 0x10100000 SSL_load_error_strings(); SSL_library_init(); OpenSSL_add_all_digests(); +#else + OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS \ + | OPENSSL_INIT_LOAD_CRYPTO_STRINGS, NULL); + OPENSSL_init_ssl(0, NULL); + OPENSSL_init_crypto(OPENSSL_INIT_ADD_ALL_DIGESTS, NULL); +#endif /* FIXME: mod_ssl does this */ X509V3_add_standard_extensions(); @@ -172,6 +179,7 @@ { struct ldapoptions *lo = LDAP_INT_GLOBAL_OPT(); +#if OPENSSL_VERSION_NUMBER < 0x10100000 EVP_cleanup(); #if OPENSSL_VERSION_NUMBER < 0x10000000 ERR_remove_state(0); @@ -179,6 +187,9 @@ ERR_remove_thread_state(NULL); #endif ERR_free_strings(); +#else + ERR_remove_thread_state(NULL); +#endif if ( lo->ldo_tls_randfile ) { LDAP_FREE( lo->ldo_tls_randfile ); --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 05 Apr '17

05 Apr '17

--On Wednesday, April 05, 2017 10:38 PM +0000 quanah(a)symas.com wrote: > --On Wednesday, April 05, 2017 7:58 PM +0000 quanah(a)symas.com wrote: > >> If openssl 1.1.0 is built with the option "no-deprecated" the build will >> fail, as portions of the code still use the pre 1.1 API. This needs >> fixing before release. > > The following 5 function calls are problematic: > > ./.libs/libldap.so: undefined reference to `OpenSSL_add_all_digests' > ./.libs/libldap.so: undefined reference to `SSL_load_error_strings' > ./.libs/libldap.so: undefined reference to `ERR_free_strings' > ./.libs/libldap.so: undefined reference to `EVP_cleanup' > ./.libs/libldap.so: undefined reference to `SSL_library_init' > > > Looking at the best way in which to fix. These also need fixing, as they don't exist in 1.1 when the old API is disabled. CRYPTO_num_locks() CRYPTO_LOCK CRYPTO_set_locking_callback() CRYPTO_set_id_callback() --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 05 Apr '17

05 Apr '17

--On Wednesday, April 05, 2017 7:58 PM +0000 quanah(a)symas.com wrote: > If openssl 1.1.0 is built with the option "no-deprecated" the build will > fail, as portions of the code still use the pre 1.1 API. This needs > fixing before release. The following 5 function calls are problematic: ./.libs/libldap.so: undefined reference to `OpenSSL_add_all_digests' ./.libs/libldap.so: undefined reference to `SSL_load_error_strings' ./.libs/libldap.so: undefined reference to `ERR_free_strings' ./.libs/libldap.so: undefined reference to `EVP_cleanup' ./.libs/libldap.so: undefined reference to `SSL_library_init' Looking at the best way in which to fix. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by quanah＠symas.com 05 Apr '17

05 Apr '17

If openssl 1.1.0 is built with the option "no-deprecated" the build will fail, as portions of the code still use the pre 1.1 API. This needs fixing before release. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#7013) OpenLDAP freezes and doesn't respond
by quanah＠symas.com 05 Apr '17

05 Apr '17

Hello, Due to inactivity and the noted improper configuration, I am closing this ITS. I would note there have been hundreds of fixes to OpenLDAP since this report was filed, including a new BDB-free backend. If you ever drop OpenDJ and move back to OpenLDAP and can reproduce the issue using back-mdb (based on LMDB), please file a new ITS. Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by ondra＠mistotebe.net 05 Apr '17

05 Apr '17

On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael Ströder wrote: > ondra(a)mistotebe.net wrote: >> On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: >>> Thanks for the patch to provide a test script that just shows the same >>> thing. >>> >>> I see two possible solutions: >>> >>> 1) replacing the same attribute twice in the same modify LDIF is illegal >>> (as it was in older releases) >> >> AFAIK, LDAP doesn't forbid it so I don't see that going away. > > Yes, there's no text in RFC 4511 which forbids this: > https://tools.ietf.org/html/rfc4511#section-4.6 > > However personally I consider LDAP clients sending modify requests like this to be > broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) I'm not saying it's common or good practice ;) > => There could be a slapd per-backend configuation directive to disallow it with a strong > hint in the docs recommending to disallow it when using delta-syncrepl. > > Suggestion: > disallow mod_attr_repeated In my view, that's more pain than it's worth. >>> 2) the accesslog/syncrepl needs to record the final result, not every bit >>> of the change. >> >> Two problems: >> - the log is meant to record the request for review/statistics purposes >> as well and should record the intent, not just the result >> - the modification might fail, in that case you still need an accurate >> record of the request > > IIRC slapo-accesslog was primarily implemented for delta-syncrepl. > > Personally I'm in the (ab)use-slapo-accesslog-as-auditlog camp. ;-) > But still I'd consider an optimized changes list written to accesslog to be perfectly > fine for security auditing because it would represent what caused the modification of the > database content. I don't think it matters what it was written for, the fact that it's officially useful for that as you and others have realised means they might object to us making drastic changes in 2.4, a series the project have tried to freeze even maintenance for. > Also note that not every failed modification is written to accesslog-DB anyway because > most malformed write operations already fail in slapd's front-end (schema check etc.) and > never reach the DB backend (and thus slapo-accesslog). So debugging errornous clients is > something for which you have to use Wireshark etc. in most cases anyway. I think most of the ones that don't reach accesslog get a protocol error or come from anonymous connections, schema checking and ACL should happen later. > I'm not familiar with the inner workings of slapd but these things should be carefully > considered when optimizing the changes list of a modify request: > 1. constraint checking (slapo-unique and slapo-constraint) > 2. impact on indexing > 3. access control, especially with val=foo part in the ACL > > 1. and 2. are hopefully already done on the "resulting entry after the entire list of > modifications is performed" (RFC 4511). Not sure I follow. On the consumer, syncrepl bypasses all ACLs and the overlays you mention should already be capable of passing the operation intact. On the provider side it depends on the overlay order and the administrator has the option to decide that if they wish. Consistency and data model are generally maintained quite alright. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by michael＠stroeder.com 05 Apr '17

05 Apr '17

ondra(a)mistotebe.net wrote: > On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: >> Thanks for the patch to provide a test script that just shows the same >> thing. >> >> I see two possible solutions: >> >> 1) replacing the same attribute twice in the same modify LDIF is illegal >> (as it was in older releases) > > AFAIK, LDAP doesn't forbid it so I don't see that going away. Yes, there's no text in RFC 4511 which forbids this: https://tools.ietf.org/html/rfc4511#section-4.6 However personally I consider LDAP clients sending modify requests like this to be broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) => There could be a slapd per-backend configuation directive to disallow it with a strong hint in the docs recommending to disallow it when using delta-syncrepl. Suggestion: disallow mod_attr_repeated >> 2) the accesslog/syncrepl needs to record the final result, not every bit >> of the change. > > Two problems: > - the log is meant to record the request for review/statistics purposes > as well and should record the intent, not just the result > - the modification might fail, in that case you still need an accurate > record of the request IIRC slapo-accesslog was primarily implemented for delta-syncrepl. Personally I'm in the (ab)use-slapo-accesslog-as-auditlog camp. ;-) But still I'd consider an optimized changes list written to accesslog to be perfectly fine for security auditing because it would represent what caused the modification of the database content. Also note that not every failed modification is written to accesslog-DB anyway because most malformed write operations already fail in slapd's front-end (schema check etc.) and never reach the DB backend (and thus slapo-accesslog). So debugging errornous clients is something for which you have to use Wireshark etc. in most cases anyway. I'm not familiar with the inner workings of slapd but these things should be carefully considered when optimizing the changes list of a modify request: 1. constraint checking (slapo-unique and slapo-constraint) 2. impact on indexing 3. access control, especially with val=foo part in the ACL 1. and 2. are hopefully already done on the "resulting entry after the entire list of modifications is performed" (RFC 4511). Ciao, Michael.

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by ondra＠mistotebe.net 05 Apr '17

05 Apr '17

On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: > Thanks for the patch to provide a test script that just shows the same > thing. > > I see two possible solutions: > > 1) replacing the same attribute twice in the same modify LDIF is illegal > (as it was in older releases) AFAIK, LDAP doesn't forbid it so I don't see that going away. > 2) the accesslog/syncrepl needs to record the final result, not every bit > of the change. Two problems: - the log is meant to record the request for review/statistics purposes as well and should record the intent, not just the result - the modification might fail, in that case you still need an accurate record of the request > I believe the easiest solution is #1. However, #2 would be proper if this > kind of abuse is legal. > > Consider the following deck: > > [...] > > Is that legal? Well, it works and results in an entry in the accesslog that > contains: > > [...] > > and has no issues in the replication. > > Therefore, why does this deck: > > dn: cn=Oh Noes,ou=People,dc=example,dc=com > changetype: modify > replace: sn > sn: Thomas > - > replace: sn > sn: George > - > > which creates an accesslog entry that contains: > > reqMod: sn:= Thomas > reqMod: sn:= George > > Interestingly, this morning when I was performing this, the replica ate that > accesslog entry and put both of those sn's into the LDAP entry on the > replica (instead of the normal barking in the logs that it failed). Perhaps > because I had done the former test with the delete/add/delete/add sequence? Your original example did two replacements with the same value, the test case runs two replacements with different values as that will cause the two servers to de-sync silently. > At this point, I'm thinking the accesslog should probably generate the > minimal changes necessary to get to the right state. That would mean the > former test should produce: > > reqMod: sn:- George > reqMod: sn:+ George > > and the latter: > > reqMod:sn:= George > > Either that, or the syncrepl processing of what accesslog is sending needs > some serious investigation. I'll see what I can find for time to look into > that serious investigation. It does need a fair bit of attention, the problem is it's something that would require a format change and there are already existing consumers that would be affected. I'm going to try with a patch to record something like this: regMod: sn:= George regMod: : regMod: sn:= George Together with the relevant syncrepl updates. While consumers would still be affected, this should be quite rare and the current handling of that case would have been incorrect anyway. The change would then only make the silent failure a noisy one. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

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