openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6765) Server-side support of "Verify Credentials" extop
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando Added module in contrib/slapd-modules/vc/; no spec yet, simply mimicking the companion of what is currently implemented in libraries/libldap/vc.c. The current code should support SASL; untested yet, since the client does not implement SASL support yet. p.

1 0

(ITS#6764) ber_flatten() should return -1 on unmatched "{" "}"
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando also per <draft-ietf-ldapext-ldap-c-api>. p.

1 0

Re: (ITS#6758) Cleaning up SlapReply usage
by hyc＠symas.com 31 Dec '10

31 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > 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:-) I think you're over-paranoid. config_build_entry() is only called by internal plumbing and the SlapReply here never gets sent to send_ldap_result(). It's only passed in because be_add() expects one; the contents are mostly irrelevant. (Aside from rs_err) -- -- 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#6758) Cleaning up SlapReply usage
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

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

1 0

(ITS#6763) slapd does not clear sr_entry/ctrls on sizelimit/busy
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

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?

1 0

(ITS#6762) cloak overlay only works on first search entry
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

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.

1 0

(ITS#6761) contrib usn overlay broken
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

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

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by B.Candler＠pobox.com 31 Dec '10

31 Dec '10

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.

1 0

(ITS#6760) rwm broken entry handling
by h.b.furuseth＠usit.uio.no 31 Dec '10

31 Dec '10

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?

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by hyc＠symas.com 30 Dec '10

30 Dec '10

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/

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