openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6778) One-time leak in generic client tools controls
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (188.153.18.39) Submitted by: ando A fix is coming. p.

1 0

Re: (ITS#6777) test014 fails
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

Sorry for the noise. The problem was real (the leak), but the solution (that free) was wrong. It's not a big deal: we usually tolerate leaks in client tools (they're mainly annoying because they cause a lot of noise in valgrind output). I'll provide a better fix some time. p.

1 0

Re: (ITS#6777) test014 fails
by quanah＠zimbra.com 04 Jan '11

04 Jan '11

--On Tuesday, January 04, 2011 9:30 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, January 04, 2011 9:16 PM +0000 quanah(a)OpenLDAP.org wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: RE24 1/4/2011 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.45.108) >> >> >> The ldapwhoami utility was recently modified to use ldap_parse_whoami. >> This change appears to have broken test014: > > This isn't ldapwhoami of course, but a library issue. :/ Modified Files: common.c 1.143 -> 1.144 Fixes it, thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6777) test014 fails
by quanah＠zimbra.com 04 Jan '11

04 Jan '11

--On Tuesday, January 04, 2011 9:16 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 1/4/2011 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > The ldapwhoami utility was recently modified to use ldap_parse_whoami. > This change appears to have broken test014: This isn't ldapwhoami of course, but a library issue. :/ --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6777) test014 fails
by quanah＠OpenLDAP.org 04 Jan '11

04 Jan '11

Full_Name: Quanah Gibson-Mount Version: RE24 1/4/2011 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) The ldapwhoami utility was recently modified to use ldap_parse_whoami. This change appears to have broken test014: Testing ldapwhoami as cn=Manager,dc=example,dc=com for dn:cn=Barbara Jensen,ou=Information Technology DivisioN,ou=People,dc=example,dc=com... ldap_parse_result: Proxied Authorization Denied (123) additional info: authzId mapping failed Result: Proxied Authorization Denied (123) Additional info: authzId mapping failed ldapwhoami failed (1)! Something seems seriously wrong with how it is parsing/passed the controls: <<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> conn=1004 op=0 BIND dn="cn=Manager,dc=example,dc=com" method=128 do_bind: version=3 dn="cn=Manager,dc=example,dc=com" method=128 ==> hdb_bind: dn: cn=Manager,dc=example,dc=com conn=1004 op=0 BIND dn="cn=Manager,dc=example,dc=com" mech=SIMPLE ssf=0 do_bind: v3 bind: "cn=Manager,dc=example,dc=com" to "cn=Manager,dc=example,dc=com" send_ldap_result: conn=1004 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 12 conn=1004 op=0 RESULT tag=97 err=0 text= connection_get(12) connection_get(12): got connid=1004 connection_read(12): checking for input on id=1004 ber_get_next ber_get_next: tag 0x30 len 76 contents: op tag 0x77, time 1294175708 ber_get_next conn=1004 op=1 do_extended ber_scanf fmt ({m) ber: => get_ctrls ber_scanf fmt ({m) ber: ber_scanf fmt (b) ber: ber_scanf fmt (m) ber: => get_ctrls: oid="2.16.840.1.113730.3.4.18" (critical) parseProxyAuthz: conn 1004 authzid="dn:cn=Ba<80><90>x" slap_sasl_getdn: conn 1004 id=dn:cn=Ba<80><90>x [len=11] >>> dnNormalize: <cn=Ba<80><90>x> => ldap_bv2dn(cn=Ba<80><90>x,0) <= ldap_bv2dn(cn=Ba<80><90>x)=0 <= get_ctrls: n=1 rc=123 err="authzId mapping failed" send_ldap_result: conn=1004 op=1 p=3 send_ldap_result: err=123 matched="" text="authzId mapping failed" send_ldap_response: msgid=2 tag=120 err=123 ber_flush2: 36 bytes to sd 12 conn=1004 op=1 RESULT tag=120 err=123 text=authzId mapping failed conn=1004 op=1 do_extended: get_ctrls failed connection_get(12) connection_get(12): got connid=1004 connection_read(12): checking for input on id=1004 ber_get_next

1 0

Re: (ITS#6773) Per-connection extra stuff
by masarati＠aero.polimi.it 04 Jan '11

04 Jan '11

> I think we can live without this feature. E.g., ppolicy, sssvlv etc. all > just > create their own private arrays of per-conn structures. Sharing here will > require introducing another mutex. Right, I've fixed things differently. I note that other code (e.g. paged results) is write-accessing its state without mutex protection; although it is unlikely that more than one search operation use paged response concurrently, this is incorrect in principle. I'm closing this ITS. p.

1 0

Re: (ITS#6746) broken slapo-translucent failure handling
by hyc＠symas.com 04 Jan '11

04 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > I've fixed it in HEAD, unless early errors in translucent_search() > should be ignored Patch looks OK, the remote server is authoritative so the first search must not fail. > or filter errors should NOT be ignored. Looks OK; as with any search if the filter doesn't match there should not be any entry returned. -- -- 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#6773) Per-connection extra stuff
by hyc＠symas.com 04 Jan '11

04 Jan '11

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it writes: >>> Unless there are objections, I'd commit it. >> >> Well, it breaks binary compatibility, but perhaps that'll break anyway? >> That is, will overlays/modules compiled with 2.4.23 break with slapd >> 2.4.24 or vice versa? > > No it won't, since I do not expect this to be released with 2.4.24 (nor > with 2.4). > > In general, yes, it will break binary compatibility, but it won't break > source code compatibility; eventuallysource code might if I move paged > results and so under the ConnExtra umbrella, which is not something I'm > struggling for at the moment. I think we can live without this feature. E.g., ppolicy, sssvlv etc. all just create their own private arrays of per-conn structures. Sharing here will require introducing another mutex. -- -- 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 04 Jan '11

04 Jan '11

In addition to the issues listed in my last message, this ITS depends on these: - ITS#6763: slapd does not clear sr_entry/ctrls on sizelimit/busy - ITS#6776: Control handling in PassMod exop + ppolicy - ITS#6760: rwm broken entry handling ==== Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> * hyc, please have a look at slapd/bconfig.c 1.419. If I have >> gotten things wrong, that one summarizes my mistakes nicely:-) I meant to say "If I've broken anything, that commit should summarize my worst mistakes." At least that worry is out of the way: > 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) Thanks. Not exactly what I hoped to hear, but I did ask... I can revert it, or since this SlapReply is so uninteresting, maybe allow rs = NULL in this case so some callers can omit it. ==== Summary of changes: * Add rs_assert_*(), disabled by default, to check SlapReply state. * Majority of changes: Avoid reusing SlapReply: Reinitialize these variables at need with rs_reinit() or move a declaration inwards (typically into loops). I think I introduced 2 new SlapReply's, in bconfig.c (unnecessarily as Howards says) ad in pcache. * Use the rs_*() functions in result.c to manage SlapReply entries, rather than freeing/releasing by hand and every so often forgetting to handle some of the REP_ENTRY_* flags. This also makes slapd more aggressive about freeing entries. E.g. result.c _released_ entries at need before sending, so entry locks for cached entries would not wait for network traffic. OTOH it did not at that point bother with entries that merely needed _freeing_. * "Reset dangerous REP_ENTRY_* flags." This is so when a module puts e.g. puts Extended Operation data in the SlapReply, another module won't try to entry_free/release() that non-entry because of some leftover REP_ENTRY_* flags. This may have been over-paranoid too: I seem closer to having rs.<sr_type, sr_un> behave like a variant record where rs.sr_type actually can be trusted. Anyway, this paranoia shouldn't hurt. Others are some minor cleanups: * Reset some SlapReply flags & data. Reset data more consistenlty. (E.g. rs_entry and flags go together, so don't reset just entry.) * Clear out or avoid filling in known unwanted info (Don't set sr_err = non-success before entering an operation handler, do not set sr_text with sr_err = LDAP_SUCCESS, etc.) * Add an error check or two (was actually done for consistency sr_err vs sr_text) * slap.h: Cast REP_* #defines to slap_mask_t * No-op changes (remove lint, rearrange/simplify code a bit, etc) -- Hallvard

1 0

Re: (ITS#6769) Slapd fails to start when olcDbURI attribute is used
by jwinius＠umrk.nl 04 Jan '11

04 Jan '11

Quoting Quanah Gibson-Mount <quanah(a)zimbra.com>: > Your information is out of date. The patch was committed last November. Excellent! At least we now know that this bug has been taken care of. Thanks, Jaap

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