openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech
by hyc＠symas.com 06 Jan '17

06 Jan '17

rick(a)openfortress.nl wrote: > Full_Name: Rick van Rein > Version: 2.4 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:980:93a5:1:98ff:3cc8:e968:ded8) > > > Hello, > > I found a nit in the OpenLDAP administrator's guide at > http://www.openldap.org/doc/admin24/guide.html#SASL%20Proxy%20Authorization > > It mentions Proxy Authorization as a facility of SASL, something I never heard > of. The fact that you've never heard of it does not indicate a bug. Read RFC2222 about authorization identities. It is defined specifically for LDAP in RFC 4370. So the chapter title, and > perhaps its ordering underneath SASL, are not perfect. > > Good luck, > -Rick > > Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8560) Proxy Authorization is mentioned as a SASL mech
by rick＠openfortress.nl 06 Jan '17

06 Jan '17

Full_Name: Rick van Rein Version: 2.4 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:980:93a5:1:98ff:3cc8:e968:ded8) Hello, I found a nit in the OpenLDAP administrator's guide at http://www.openldap.org/doc/admin24/guide.html#SASL%20Proxy%20Authorization It mentions Proxy Authorization as a facility of SASL, something I never heard of. It is defined specifically for LDAP in RFC 4370. So the chapter title, and perhaps its ordering underneath SASL, are not perfect. Good luck, -Rick

1 0

(ITS#8559) Syncrepl stuck after duplicated attribute modification on master
by matheus_morais＠sicredi.com.br 06 Jan '17

06 Jan '17

Full_Name: Matheus Morais Version: 2.4.42 OS: Red Hat 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (201.77.94.55) In an environment with syncrepl properly configured, if one modification with duplicated attributes values is applied on the "master" node, the "slave" stuck the replication until the entry is removed from cn=accesslog. Here is one LDIF example: dn: ou=marili_advogados,ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc=com,dc=br changetype: modify - replace: SicrediEntidadePai SicrediEntidadePai: ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc=com,dc=br - replace: SicrediEntidadePai SicrediEntidadePai: ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc=com,dc=br This change is processed by master and appears like that on the cn=accesslog: dn: reqStart=20170103135721.000411Z,%3=accesslog objectClass: auditModify reqStart: 20170103135721.000411Z reqEnd: 20170103135721.000413Z reqType: modify reqSession: 1184351 reqAuthzID: cn=manager,dc=br reqControls: {0}{2.16.840.1.113730.3.4.2} reqDN: ou=marili_advogados,ou=terceiros,%n=sistema,cn=entities,dc=sicredi,dc=c om,dc=br reqResult: 0 reqMod: SicrediEntidadePai:= ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc =com,dc=br reqMod: SicrediEntidadePai:= ou=terceiros,cn=sistema,cn=entities,dc=sicredi,dc =com,dc=br reqMod: entryCSN:= 20170103135721.874447Z#000000#000#000000 reqMod: modifiersName:= cn=manager,dc=br reqMod: modifyTimestamp:= 20170103135721Z reqEntryUUID: 61dfd779-5799-4988-927b-914e75d6ae90 When the slaves try to apply that change, it results in a constraint violation. We can see that kind of message on the slaves logs: 2017-01-03T19:14:21.043501-02:00 ds1openldap5p slapd[2245]: syncrepl_message_to_op: rid=000 mods check (SicrediEntidadePai: multiple values provided) 2017-01-03T19:14:21.043599-02:00 ds1openldap5p slapd[2245]: do_syncrepl% r rid=000 rc 19 retrying 2017-01-03T19:15:21.039822-02:00 ds1openldap5p slapd[2245]: syncrepl_message_to_op: rid=000 mods check (SicrediEntidadePai: multiple values provided) 2017-01-03T19:15:21.039863-02:00 ds1openldap5p slapd[2245]: do_syncrepl: rid=000 rc 19 retrying I think we have two options here: 1 - This kind of LDIF should result in a constraint violation on the master node and the modification is not recorded on cn=accesslog. 2 - The accesslog overlay should remove the duplicated values from attributes. The first option seems more rational IMHO.

1 0

(ITS#8558) LMDB mdb_load plain text
by remy.chibois＠expandium.com 06 Jan '17

06 Jan '17

Full_Name: Remy Chibois Version: LMDB_0.9+ OS: Debian "Jessie" URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (46.218.8.100) when loading data into a LMDB database using plain text mode (mdb_load -T), escaped hexadecimal pairs (such as \09 for a tab character) cause data to be incorrectly converted. Replacing mdb_load.c line 251 with "*c1++ = *c2++;"nsnstead of "c1++; c2++;" fixes the issue (after the first escaped sequence, characters from c2 pointer need to be copied to c1 pointer in order to properly overwrite escaped sequence).

1 0

Re: (ITS#8555) slapo-pcache forgets credentials for binddn
by hyc＠symas.com 05 Jan '17

05 Jan '17

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.44 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.26) > > > When slapo-pcache is set up to use the user credentials for binding, the first > bind will succeed accordingly, but subsequent binds will fall back to anonymous, > as slapd logs that the credentials are not found: > > 58645256 conn=1024 op=1 ldap_back_dobind_int: DN="cn=james a jones 1,ou=alumni > association,ou=people,dc=example,dc=com" without creds, binding > anonymouslyldap_sasl_bind > > > This is trivial to reproduce by making a slight modification to > test020-proxycache: > > index f4e5cb7..105b911 100755 > --- a/tests/scripts/test020-proxycache > +++ b/tests/scripts/test020-proxycache > @@ -645,6 +645,22 @@ if test $RC != 4 ; then > test $KILLSERVERS != no && kill -HUP $KILLPIDS && wait > exit 1 > fi > + > +CNT=`expr $CNT + 1` > +FILTER="(sn=Jon)" > +ATTRS="cn mail telephonenumber" > +echo "Query $CNT: (Result should not be cached)" > +echo "# Query $CNT: (Result should not be cached)" >> $SEARCHOUT > +$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT2 \ > + -D "$USERDN" -w "$UPASSWD" "$FILTER" $ATTRS >> $SEARCHOUT 2>> $TESTOUT > +RC=$? > + > +if test $RC != 0 ; then > + echo "ldapsearch failed ($RC)!" > + test $KILLSERVERS != no && kill -HUP $KILLPIDS > + exit $RC > +fi > + > > > The error test case isn't useful here, but slapd.2.log can be examined to see > the behavior. > > It appears that there's a problem with this block of code in back-ldap/bind.c, > that starts at line 2489 in RE24: This title is misleading. slapo-pcache doesn't forget anything. The point is that when slapo-pcache is configured to cache Binds, if a Bind is answerable from the cache then pcache answers it and the underlying backend doesn't ever see the Bind request. slapo-pcache is working as designed. back-ldap is also working as designed, in test020. In particular, it cannot do an authenticated connection to the remote backend unless you configure proxyAuthz or rebind-as-user and neither of those are set in the test020 config. Without either of these possibilities for providing authentication/authorization, it of course must connect anonymously to the remote. Also rebind-as-user won't work here since back-ldap only caches those credentials for the duration of one session. So, the only method that will work is to use proxyAuthz. -- -- 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#8557) mdb_put may cause a cursor malfunction
by h.b.furuseth＠usit.uio.no 05 Jan '17

05 Jan '17

On 03/01/17 22:04, lazarev.michael(a)gmail.com wrote: > After a number of mdb_put calls, mdb_cursor_get with MDB_LAST operation > positions the cursor incorrectly. Test code is submitted here: > ftp://ftp.openldap.org/incoming/mdb_put_test.c The C_EOF flag is doubly broken here, and maybe ill-defined: Previous mdb_cursor_last() set C_EOF as a "cursor is on the last page" hint, cursor_put() did not clear it in this cursor when putting through another cursor, and then next cursor_last() uses the hint in "if (!(mc->mc_flags & C_EOF))" when the cursor is no longer at the end. However, elsewhere the flag is seen as "cursor is beyond last item": mdb_cursor_next(), MDB_GET_MULTIPLE, mdb_cursor_count(). It is set that way after mdb_cursor_sibling(<right>) fails. But it's not used consistently that way either: At least MDB_GET_CURRENT, MDB_PREV, put(MDB_CURRENT) succeed with C_EOF set. (And they don't move the cursor to the last item first.) As for the "cursor is on last page" hint, page_search() & co could at least avoid some page_get()s without using C_EOF: If C_INITIALIZED is set, then while mc_pg[] and mc_ki[] are correct it can just walk down the cursor without doing page_get(). If a _pg or _ki needs to change, it can switch to the regular page_seaarch() code. Helps write-txns and MDB_VL32, but not read-only txns.

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by sca＠andreasschulze.de 03 Jan '17

03 Jan '17

Am 03.01.2017 um 20:12 schrieb Howard Chu: > sca(a)andreasschulze.de wrote: >> Am 28.11.2016 um 17:42 schrieb Quanah Gibson-Mount: >>> I have a few additional comments: >>> ... >> >> I updated the patch as suggested: ftp://ftp.openldap.org/incoming/andreas-schulze-161204.patch > > +/* REVIEW: CRYPTO_num_locks is defined as "(1)" openssl-1.1.0 */ > +static ldap_pvt_thread_mutex_t tlso_mutexes[CRYPTO_num_locks()]; > > This is not acceptable. The fact that the macro is defined as a function macro implies that it may be turned into a genuine function at some point in the future. Either we get a commitment from the OpenSSL developers that this macro will always be a constant, or the code must change to dynamically allocate the mutexes array. > > @@ -882,6 +924,9 @@ static BIO_METHOD tlso_bio_method = > tlso_bio_create, > tlso_bio_destroy > }; > +#else > +static BIO_METHOD *tlso_bio_method = NULL; > +#endif > > static int > tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg ) > @@ -898,8 +943,29 @@ tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg ) > > p->session = arg; > p->sbiod = sbiod; > +#if OPENSSL_VERSION_NUMBER < 0x10100000L > bio = BIO_new( &tlso_bio_method ); > bio->ptr = (void *)p; > +#else > + if ( tlso_bio_method == NULL ) { > + tlso_bio_method = BIO_meth_new(( 100 | 0x400 ), "sockbuf glue"); > + if ( tlso_bio_method == NULL > + || !BIO_meth_set_write(tlso_bio_method, tlso_bio_write) > + || !BIO_meth_set_read(tlso_bio_method, tlso_bio_read) > + || !BIO_meth_set_puts(tlso_bio_method, tlso_bio_puts) > + || !BIO_meth_set_gets(tlso_bio_method, tlso_bio_gets) > + || !BIO_meth_set_ctrl(tlso_bio_method, tlso_bio_ctrl) > + || !BIO_meth_set_create(tlso_bio_method, tlso_bio_create) > + || !BIO_meth_set_destroy(tlso_bio_method, tlso_bio_destroy)) { > + return -1; > + } > + } > + bio = BIO_new(tlso_bio_method); > + if ( bio == NULL ) { > + return -1; > + } > + BIO_set_data(bio, (void *)p); > +#endif > > This is no good, the tlso_bio_method must be initialized once and only once. The structure can be referenced simultaneously from multiple threads, and initing on each use will be a performance hit as well as a waste of memory. Hello Howard, looks like you're much more familiar with open[ssl|ldap] insides. My intension was to show a way to build openldap with openssl-1.1.0. I'm aware that is not ideal and you prove that now. Thanks. But I cannot contribute better code. Sorry. Andreas

1 0

(ITS#8557) mdb_put may cause a cursor malfunction
by lazarev.michael＠gmail.com 03 Jan '17

03 Jan '17

Full_Name: Michael Lazarev Version: OS: Linux, FreeBSD URL: ftp://ftp.openldap.org/incoming/mdb_put_test.c Submission from: (NULL) (128.70.151.136) After a number of mdb_put calls, mdb_cursor_get with MDB_LAST operation positions the cursor incorrectly. Test code is submitted here: ftp://ftp.openldap.org/incoming/mdb_put_test.c

1 0

Re: (ITS#8556) OpenLDAP technical support listing
by quanah＠symas.com 03 Jan '17

03 Jan '17

--On Tuesday, January 03, 2017 10:54 AM +0000 marketing(a)rosehosting.com wrote: > We'd really appreciate it if you add us to the list. Done, and will be listed on the next website push, which will coincide with the OpenLDAP 2.4.45 release (So may be a little bit). Regards, 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 hyc＠symas.com 03 Jan '17

03 Jan '17

sca(a)andreasschulze.de wrote: > Am 28.11.2016 um 17:42 schrieb Quanah Gibson-Mount: >> I have a few additional comments: >> ... > > I updated the patch as suggested: ftp://ftp.openldap.org/incoming/andreas-schulze-161204.patch +/* REVIEW: CRYPTO_num_locks is defined as "(1)" openssl-1.1.0 */ +static ldap_pvt_thread_mutex_t tlso_mutexes[CRYPTO_num_locks()]; This is not acceptable. The fact that the macro is defined as a function macro implies that it may be turned into a genuine function at some point in the future. Either we get a commitment from the OpenSSL developers that this macro will always be a constant, or the code must change to dynamically allocate the mutexes array. @@ -882,6 +924,9 @@ static BIO_METHOD tlso_bio_method = tlso_bio_create, tlso_bio_destroy }; +#else +static BIO_METHOD *tlso_bio_method = NULL; +#endif static int tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg ) @@ -898,8 +943,29 @@ tlso_sb_setup( Sockbuf_IO_Desc *sbiod, void *arg ) p->session = arg; p->sbiod = sbiod; +#if OPENSSL_VERSION_NUMBER < 0x10100000L bio = BIO_new( &tlso_bio_method ); bio->ptr = (void *)p; +#else + if ( tlso_bio_method == NULL ) { + tlso_bio_method = BIO_meth_new(( 100 | 0x400 ), "sockbuf glue"); + if ( tlso_bio_method == NULL + || !BIO_meth_set_write(tlso_bio_method, tlso_bio_write) + || !BIO_meth_set_read(tlso_bio_method, tlso_bio_read) + || !BIO_meth_set_puts(tlso_bio_method, tlso_bio_puts) + || !BIO_meth_set_gets(tlso_bio_method, tlso_bio_gets) + || !BIO_meth_set_ctrl(tlso_bio_method, tlso_bio_ctrl) + || !BIO_meth_set_create(tlso_bio_method, tlso_bio_create) + || !BIO_meth_set_destroy(tlso_bio_method, tlso_bio_destroy)) { + return -1; + } + } + bio = BIO_new(tlso_bio_method); + if ( bio == NULL ) { + return -1; + } + BIO_set_data(bio, (void *)p); +#endif This is no good, the tlso_bio_method must be initialized once and only once. The structure can be referenced simultaneously from multiple threads, and initing on each use will be a performance hit as well as a waste of memory. -- -- 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

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