December 2010 - openldap-bugs

Re: (ITS#6758) Cleaning up SlapReply usage

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

Mostly done with the easily spotted cases. Hopefully HEAD's code stayed valid through my commits. Need to think some more for the rest. The decisions with greater chance of breaking things remain, like ITS#6763. Other issues: * hyc, please have a look at slapd/bconfig.c 1.419. If I have gotten things wrong, that one summarizes my mistakes nicely:-) * If slap_send_ldap_result() or send_ldap_disconnect() see an entry with REP_ENTRY_MUST<RELEASE/BEFREED> and REP_SEARCH/SEARCHREF, should release/free the entry? That helps code which sends error without freeing sr_entry. It breaks if the entry comes from another Operation, or if the caller reuses a Search SlapReply for a non-Search and trusts rs->sr_un.sru_search to stay untouched. * Is the code getting clean enough that slap_send_search_entry's cleanup code can flush the entry independently of whether op->o_tag == LDAP_REQ_SEARCH? * slapi/slapi_pblock.c 1.81: /* TODO: Should REP_ENTRY_MODIFIABLE be set? */ I've no idea, and I've more pressing things to look at... Notes on the updates: * "Reset some SlapReply flags & data" commits vs "avoid SlapReply reuse" commits: The combination might be redundant/overcautious, but tries to catch problems from remaining unclean code from both ends. * result.c, freeing as well as releasing entries as soon as possible: More readable, and since the entry isn't needed: The sooner we get rid of it, the less chance for an entry leak. * commits "Use rs_*() to manage SlapReply entries." Switching to rs_flush_entry(): - result.c:slap_send_search_entry(), overlays/pcache.c, overlays/translucent.c, slapi/slapi_pblock.c: These did not clear the MODIFIABLE flag along with MUSTBEFREED. Switching to use rs_ensure_entry_modifiable(): - syncprov_operational(), overlay collect: noop change (except operational should not update the entry) - overlay valsort: It needlessly required REP_ENTRY_MUSTBEFREED as well as MODIFIABLE. But the entry can also be MODIFIABLE and e.g. on the stack. - contrib overlays cloak, usn: Had entry leaks. -- Hallvard

12 years, 2 months

1
0
0 / 0

(ITS#6763) slapd does not clear sr_entry/ctrls on sizelimit/busy

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

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slap_send_search_entry() does not always free/release the entry and call slap_cleanup_play() on error. slap_send_search_reference() calls slap_cleanup_play(), but does not always free/release the entry. I expect both functions always should do both, but don't know enough myself to be sure. Resolution needed for ITS#6758 (SlapReply) - who should be responsible for clearing out the entry?

12 years, 2 months

1
0
0 / 0

(ITS#6762) cloak overlay only works on first search entry

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

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard The cloak overlay only works on the first entry returned from a search. Then it removes the callback, and the remaining attributes are uncloaked. I checked this by removing the call to slap_freeself_cb() and the setting of sc_cleanup, then it worked. And probably got a leak somewhere, but I don't have time to find the right fix now.

12 years, 2 months

1
0
0 / 0

(ITS#6761) contrib usn overlay broken

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

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard The usn overlay: - Has init function usn_init instead of usn_initialize. - Won't start, the attributes need a SYNTAX slapd knows and USAGE directoryOperation after NO-USER-MODIFICATION. - Modifies sr->sr_entry in usn_operational() instead of putting the attribute in rs->sr_operational_attrs. See back-bdb/operational.c for an example. Note, backend.c says /* NOTE: backend_operational() is also called * when returning results, so it's supposed * to do no harm to entries */ which presumably means something more than just having to dup the entry and set MUSTBEFREED, since otherwise that comment applies to much more than just backend_operational(). In fact, usn_operational() has some misindented code if ( !a ) { for ( ap = &rs->sr_operational_attrs; *ap; ap=&(*ap)->a_next ); a = attr_alloc( ad_usnChanged ); *ap = a; } which looks like it does something closer to that. - When I tried to slapadd some entires (using Octet String syntax) only the first entry got an USN. Oh well, this wasn't what I was supposed to be doing today. I'm just patching the overlay blindly for some other things (ITS#6758).

12 years, 2 months

1
0
0 / 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented

by B.Candler＠pobox.com

I get similar behaviour using Cyrus SASL's sample-client and sample-server: ... Negotiation complete Username: student(a)REALM3.WS.NSRC.ORG Realm: (NULL) SSF: 56 ... Now, in sample-server.c, the displayed realm comes from result = sasl_getprop(conn, SASL_DEFUSERREALM, (const void **)&data); which suggests this is intended to be the default realm, not the realm of the user connecting. And clearly the username does include the Kerberos realm. But I'm having difficulty finding the corresponding OpenLDAP code to extract the realm. Is it making use of session callbacks, and expects Cyrus to call slap_sasl_canonicalize (SASL_CB_CANON_USER) with the user_realm parameter? Regards, Brian.

12 years, 2 months

1
0
0 / 0

(ITS#6760) rwm broken entry handling

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

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard rwm_entry_get_rw() returns failure with an entry in *ep if rwm_send_entry() fails. rwm_send_entry() does not honor REP_ENTRY_MUSTBEFREED. And its ITS#6423 bugcatch can be done before entry_dup(). Fixing - I think - but my fix could use some extra eyes. In particuar, am I right about using be_entry_release_r() or should it have used overlay_entry_release_ov() which rs_replace_entry() uses? Or should rwm_send_entry() use different release methods depending on whether it is called by rwm.on_response or rwm.on_bi.bi_entry_get_rw?

12 years, 2 months

1
0
0 / 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented

by hyc＠symas.com

b.candler(a)pobox.com wrote: > Full_Name: Brian Candler > Version: 2.4.21 > OS: Ubuntu 10.04.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (87.114.104.19) > > > DOcumentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI gives two > example authorization DNs built from SASL/GSSAPI: > > "a user with the Kerberos principal kurt(a)EXAMPLE.COM would have the associated > DN: > uid=kurt,cn=example.com,cn=gssapi,cn=auth > and the principal ursula/admin(a)FOREIGN.REALM would have the associated DN: > uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth" > > Experimentation shows that the actual behaviour is different. > > You could treat this either as a behaviour error or a documentation error - if > the latter, the olcSaslRealm is pretty useless, because if set it appears in all > auth DNs (for both local and foreign realms) Could be a bug, but we're using the parameters as documented by Cyrus. I suggest you file this bug report with them instead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 2 months

1
0
0 / 0

Re: (ITS#6755) ldapsearch crashes - double free or corruption (!prev): 0x0989f5f8

by hyc＠symas.com

jgilmour(a)techsmog.com wrote: > Full_Name: Josh Gilmour > Version: ldapsearch 2.3.43 (Nov 29 2010 03:47:14) > OS: CentOS release 5.4 32bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (38.112.23.58) > > > I get a segfault when using the following command and applying a filter file. If > we remove the -f, the command runs properly. It doesn't seem to be a major > security issue (or one at all, I'm not sure), but it does seem to be a bug I > believe... OpenLDAP 2.3 is no longer supported. If you can reproduce this bug in a current release please followup with the relevant stack trace, otherwise this ITS will be closed. Currently I see no such symptom in 2.4.x. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 2 months

1
0
0 / 0

ITS#6678

by hyc＠symas.com

The best thing to do in a hang situation is to attach to the server with gdb and get a stack trace of all of the active threads. http://www.openldap.org/faq/data/cache/59.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 years, 2 months

1
0
0 / 0

Re: (ITS#6670) memberof overlay problem

by hyc＠symas.com

henjes(a)informatik.uni-wuerzburg.de wrote: > Full_Name: Robert Henjes > Version: 2.4.23-4 > OS: Debian Squeeze > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.187.12.89) > > > Hi, > > while using memberof overlay I recognized the following problem in conjunction > with groupOfNames. If you try to add an empty group of names you have to set at > least one member attribute, since it is mandatory. One could have the idea to > point to the group dn itself. If having the memberof overlay active this leads > to a loop while executing an ldapadd. I assume this happens while the memberof > overlay is triggered. Tried to analyze the slapd debug output, but it stops, > after the addition is completed. > > Example LDIF file: > dn: cn=stupid,ou=groups,dc=domain > objectClass: top > objectClass: groupOfNames > cn: stupid > member: cn=stupid,ou=groups,dc=domain > > The slapd server seems proceed working, except the add process and the subtree > where the LDIF is gets added. You can not stop the slapd server in a normal way, > you just have to do a "kill -9". After that the LDIF file seems to be added, but > I assume, that the memberof overlay representation is inconsistent. > > The memberof overlay should be aware of such situations, even if building loops > in dn references is in general not a good idea. The memberof code in HEAD has been patched to ignore these cases. Possibly we can add additional code to insert the member/memberOf value as appropriate, but I haven't done so in this patch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

12 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 December 2010