January 2017 - openldap-bugs

(ITS#8563) Documentation inconsistency for syncrepl for mdb

by dpa-openldap＠aegee.org

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4.44 OS: any URL: Submission from: (NULL) (141.2.134.77) The manual states in section 5.2.5.8 olcSyncrepl, second last paragraph: "The syncrepl replication mechanism is supported by the bdb and hdb backends". This text above is repeated in section 6.2.3.7 syncrepl. But in section 18.1.1.2. Syncrepl Details, fourth paragraph, is written 'The syncrepl engine, which is a consumer-side replication engine, can work with any backends. The LDAP Sync provider can be configured as an overlay on any backend, but works best with the back-bdb back-hdb, or back-mdb backends.' Can syncrepl work with any backend and does it work with bdb equally good as with mdb?

6 years, 2 months

1
0
0 / 0

(ITS#8562) Typos in the documentation

by dpa-openldap＠aegee.org

Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1086;&#1074; Version: 2.4.44 OS: any URL: Submission from: (NULL) (141.2.134.77) In the manual, - section 8.2.5 Access Control Examples, 2nd paragraph replace "allows anonymous to authentication against these entries" with "authenticate"; - section 13.2.4 Attibute Type Specification, 4th code snippet, replace "DESC 'common name(s) assciated with the object" with "associated"; - section8.8.1.1 LDAP Sync Replication, last paragraph, replace "is defined by a general search criteria consisting of base and scope': remove the 'a' in front of criteria. - section 20 Monitoring, 3rd paragraph "This information can be access with ldapsearch", substitute with "accessed".

6 years, 2 months

1
0
0 / 0

(ITS#8561) ppolicy overlay and MMR delta-sync lost sync on switching to REFRESH

by bhalsema＠purdue.edu

Full_Name: Beth Halsema Version: 2.4.44 OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.210.177.153) The ppolicy overlay attempts to perform an LDAP_MOD_DELETE on attributes that have already been removed via a SLAP_MOD_SOFTDEL. This results in an error like the following: bdb_modify_internal: 16 modify/delete: pwdGraceUseTime: no such attribute bdb_modify: modify failed (16) send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=16 matched="" text="modify/delete: pwdGraceUseTime: no such attribute" null_callback : error code 0x10 slap_graduate_commit_csn: removing 0x7f38bc11c4c0 20170106184533.027966Z#000000#001#000000 syncrepl_message_to_op: rid=001 be_modify uid=nd,ou=People,dc=example,dc=com (16) ... do_syncrep2: rid=001 delta-sync lost sync on (reqStart=20170106184533.000001Z,cn=log), switching to REFRESH I will be uploading a tarfile th c contains a test script, ldif files (used by the test script), and a suggested patch. We have performed limited testing which demonstrated desirable behavior. NOTE: The test script looks for the LDIFs in the DATADIR. I tested the script using the openldap-2.4.44/tests/run script.

6 years, 2 months

1
0
0 / 0

Re: (ITS#8558) LMDB mdb_load plain text

by hyc＠symas.com

remy.chibois(a)expandium.com wrote: > 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). > > Thanks, fixed in git. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

6 years, 2 months

1
0
0 / 0

Re: (ITS#8560) Proxy Authorization is mentioned as a SASL mech

by hyc＠symas.com

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/

6 years, 2 months

1
0
0 / 0

(ITS#8560) Proxy Authorization is mentioned as a SASL mech

by rick＠openfortress.nl

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

6 years, 2 months

1
0
0 / 0

(ITS#8559) Syncrepl stuck after duplicated attribute modification on master

by matheus_morais＠sicredi.com.br

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.

6 years, 2 months

1
0
0 / 0

(ITS#8558) LMDB mdb_load plain text

by remy.chibois＠expandium.com

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).

6 years, 2 months

1
0
0 / 0

Re: (ITS#8555) slapo-pcache forgets credentials for binddn

by hyc＠symas.com

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/

6 years, 2 months

1
0
0 / 0

Re: (ITS#8557) mdb_put may cause a cursor malfunction

by h.b.furuseth＠usit.uio.no

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.

6 years, 2 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2017