openldap-bugs April 2010

openldap-bugs@openldap.org

45 participants
233 discussions

Re: (ITS#6505) ldap_search_* functions missing const qualifiers
by EHASZLA＠transunion.com 02 Apr '10

02 Apr '10

hmm... I'm not quite sure how to attach a file to a ticket through the web interface, so I'm just going to paste the patches in here: --- ldap.h.1.349.orig 2010-04-02 15:32:34.113126200 -0500 +++ ldap.h 2010-04-02 15:33:55.252793400 -0500 @@ -1841,7 +1841,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **serverctrls, LDAPControl **clientctrls, @@ -1855,7 +1855,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **serverctrls, LDAPControl **clientctrls, @@ -1870,7 +1870,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly )); =20 LDAP_F( int ) @@ -1879,7 +1879,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPMessage **res )); =20 @@ -1889,7 +1889,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, struct timeval *timeout, LDAPMessage **res )); --- search.c.1.88.orig 2010-04-02 15:26:34.268550800 -0500 +++ search.c 2010-04-02 15:32:36.939198200 -0500 @@ -47,7 +47,7 @@ * attrsonly 1 =3D> attributes only 0 =3D> attributes and values * * Example: - * char *attrs[] =3D { "mail", "title", 0 }; + * const char *attrs[] =3D { "mail", "title", 0 }; * ldap_search_ext( ld, "dc=3Dexample,dc=3Dcom", LDAP_SCOPE_SUBTREE, "cn~=3Dbob", * attrs, attrsonly, sctrls, ctrls, timeout, sizelimit, * &msgid ); @@ -58,7 +58,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -76,7 +76,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -139,7 +139,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -157,7 +157,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -210,14 +210,14 @@ * attrsonly 1 =3D> attributes only 0 =3D> attributes and values * * Example: - * char *attrs[] =3D { "mail", "title", 0 }; + * const char *attrs[] =3D { "mail", "title", 0 }; * msgid =3D ldap_search( ld, "dc=3Dexample,dc=3Dcom", LDAP_SCOPE_SUBTREE, "cn~=3Dbob", * attrs, attrsonly ); */ int ldap_search( LDAP *ld, LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, int attrsonly ) + LDAP_CONST char **attrs, int attrsonly ) { BerElement *ber; ber_int_t id; @@ -246,7 +246,7 @@ LDAP_CONST char *base, ber_int_t scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, ber_int_t attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -390,7 +390,7 @@ int ldap_search_st( LDAP *ld, LDAP_CONST char *base, int scope, - LDAP_CONST char *filter, char **attrs, + LDAP_CONST char *filter, LDAP_CONST char **attrs, int attrsonly, struct timeval *timeout, LDAPMessage **res ) { int msgid; @@ -419,7 +419,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPMessage **res ) {

1 0

(ITS#6505) ldap_search_* functions missing const qualifiers
by ehaszla＠transunion.com 02 Apr '10

02 Apr '10

Full_Name: Eric Haszlakiewicz Version: cvsweb OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.106.254.66) The ldap_search_ext, ldap_search_ext_s, ldap_search, ldap_search_s and ldap_search_st functions should use const for the attrs parameter. I checked revision 1.88 of libraries/libldap/search.c and it appears that those strings do not get modified so there is no reason that a list of string constants couldn't be passed in. I have a short patch that changes libraries/libldap/search.c and include/ldap.h (rev 1.349) to add the const qualifier.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> masarati(a)aero.polimi.it wrote: >>> masarati(a)aero.polimi.it wrote: >>>>> Also, I note that the glued paged response seems to work incorrectly. >>>>> I >>>>> made a simple test system, where the root database contains exactly >>>>> one >>>>> entry (the suffix) and a back-ldap is glued on top. If I request >>>>> entries >>>>> with a page size of 2, searching the suffix return 3 entries; >>>>> subsequent >>>>> searches return 2 entries from the proxy. I haven't figured out yet >>>>> where >>>>> the issue is. >>>> >>>> I figured out how to fix the issue you reported. It is related to the >>>> fact that slapd internally assumes that ldctl_oid values are constant >>>> strings, so it doesn't duplicate nor free them. However, control OIDs >>>> returned by back-ldap (and friends) have been decoded from the wire by >>>> the >>>> client library, so they are actually malloc'ed. That's why backglue >>>> ends >>>> up with a dangling pointer. >>>> >>>> I'm fixing it by having backglue duplicate (and free) control OIDs >>>> consistently. Another option would be to replace those values with >>>> constant strings for known control values. This would prevent gluing >>>> for >>>> unknown proxied controls. >>> >>> Or just tmpalloc them and don't bother to clean them up. >> >> Yes, I've reworked all the temporary controls allocation using tmpalloc. >> Too bad OIDs are char* and not bervals. >> >> With respect to the other issue, to honor the requested pagesize we'd >> need >> to intercept pagedresult requests, modify the page size in the request >> when a page crosses two databases, requesting the original page size >> minus >> entries already returned. I wonder whether it's worth the effort, >> though. > > IMO pagedresults should be a (global) overlay, and backends shouldn't do > anything about it. Note that the sssvlv overlay already intercepts > pagedresults, it's impossible to handle things correctly otherwise. Well, I've just fixed it. When changing database, I modified the paged results control value by setting the page size to pagesize - rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I only have http access. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by hyc＠symas.com 01 Apr '10

01 Apr '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>>> Also, I note that the glued paged response seems to work incorrectly. >>>> I >>>> made a simple test system, where the root database contains exactly one >>>> entry (the suffix) and a back-ldap is glued on top. If I request >>>> entries >>>> with a page size of 2, searching the suffix return 3 entries; >>>> subsequent >>>> searches return 2 entries from the proxy. I haven't figured out yet >>>> where >>>> the issue is. >>> >>> I figured out how to fix the issue you reported. It is related to the >>> fact that slapd internally assumes that ldctl_oid values are constant >>> strings, so it doesn't duplicate nor free them. However, control OIDs >>> returned by back-ldap (and friends) have been decoded from the wire by >>> the >>> client library, so they are actually malloc'ed. That's why backglue >>> ends >>> up with a dangling pointer. >>> >>> I'm fixing it by having backglue duplicate (and free) control OIDs >>> consistently. Another option would be to replace those values with >>> constant strings for known control values. This would prevent gluing >>> for >>> unknown proxied controls. >> >> Or just tmpalloc them and don't bother to clean them up. > > Yes, I've reworked all the temporary controls allocation using tmpalloc. > Too bad OIDs are char* and not bervals. > > With respect to the other issue, to honor the requested pagesize we'd need > to intercept pagedresult requests, modify the page size in the request > when a page crosses two databases, requesting the original page size minus > entries already returned. I wonder whether it's worth the effort, though. IMO pagedresults should be a (global) overlay, and backends shouldn't do anything about it. Note that the sssvlv overlay already intercepts pagedresults, it's impossible to handle things correctly otherwise. -- -- 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#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> masarati(a)aero.polimi.it wrote: >>> Also, I note that the glued paged response seems to work incorrectly. >>> I >>> made a simple test system, where the root database contains exactly one >>> entry (the suffix) and a back-ldap is glued on top. If I request >>> entries >>> with a page size of 2, searching the suffix return 3 entries; >>> subsequent >>> searches return 2 entries from the proxy. I haven't figured out yet >>> where >>> the issue is. >> >> I figured out how to fix the issue you reported. It is related to the >> fact that slapd internally assumes that ldctl_oid values are constant >> strings, so it doesn't duplicate nor free them. However, control OIDs >> returned by back-ldap (and friends) have been decoded from the wire by >> the >> client library, so they are actually malloc'ed. That's why backglue >> ends >> up with a dangling pointer. >> >> I'm fixing it by having backglue duplicate (and free) control OIDs >> consistently. Another option would be to replace those values with >> constant strings for known control values. This would prevent gluing >> for >> unknown proxied controls. > > Or just tmpalloc them and don't bother to clean them up. Yes, I've reworked all the temporary controls allocation using tmpalloc. Too bad OIDs are char* and not bervals. With respect to the other issue, to honor the requested pagesize we'd need to intercept pagedresult requests, modify the page size in the request when a page crosses two databases, requesting the original page size minus entries already returned. I wonder whether it's worth the effort, though. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by hyc＠symas.com 01 Apr '10

01 Apr '10

masarati(a)aero.polimi.it wrote: >> Also, I note that the glued paged response seems to work incorrectly. I >> made a simple test system, where the root database contains exactly one >> entry (the suffix) and a back-ldap is glued on top. If I request entries >> with a page size of 2, searching the suffix return 3 entries; subsequent >> searches return 2 entries from the proxy. I haven't figured out yet where >> the issue is. > > I figured out how to fix the issue you reported. It is related to the > fact that slapd internally assumes that ldctl_oid values are constant > strings, so it doesn't duplicate nor free them. However, control OIDs > returned by back-ldap (and friends) have been decoded from the wire by the > client library, so they are actually malloc'ed. That's why backglue ends > up with a dangling pointer. > > I'm fixing it by having backglue duplicate (and free) control OIDs > consistently. Another option would be to replace those values with > constant strings for known control values. This would prevent gluing for > unknown proxied controls. Or just tmpalloc them and don't bother to clean them up. -- -- 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#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> Also, I note that the glued paged response seems to work incorrectly. I > made a simple test system, where the root database contains exactly one > entry (the suffix) and a back-ldap is glued on top. If I request entries > with a page size of 2, searching the suffix return 3 entries; subsequent > searches return 2 entries from the proxy. I haven't figured out yet where > the issue is. I figured out how to fix the issue you reported. It is related to the fact that slapd internally assumes that ldctl_oid values are constant strings, so it doesn't duplicate nor free them. However, control OIDs returned by back-ldap (and friends) have been decoded from the wire by the client library, so they are actually malloc'ed. That's why backglue ends up with a dangling pointer. I'm fixing it by having backglue duplicate (and free) control OIDs consistently. Another option would be to replace those values with constant strings for known control values. This would prevent gluing for unknown proxied controls. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

>> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.57.67.241) >> >> >> This is similar to ITS #5191 (http://www.openldap.org/its/?findid=5191), >> except >> it happens with a subordinate LDAP database. >> >> Consider this configuration : >> 8<--------------------------------------- >> database ldap >> suffix "o=test,o=sub" >> uri "ldap://localhost:1234" >> subordinate >> idassert-bind mode=none bindmethod=simple flags=prescriptive timeout=0 >> network-timeout=0 binddn="cn=svc,o=test" credentials="verysecret" >> idassert-authzFrom dn.regex:.* >> single-conn yes >> >> overlay rwm >> rwm-suffixmassage "o=test,o=sub" "o=test" >> >> database null >> suffix "o=sub" >> rootdn "cn=Manager,o=sub" >> rootpw secret >> overlay glue >> 8<--------------------------------------- >> >> A search with pagedResults control returns results as expected, but with >> a >> response control containing some garbage: >> >> result: 0 Success >> control:: >> qOEpCDg0MC4xMTM1NTYuMS40LjMxOSBmYWxzZSBNSVFBQUFBSkFnRUFCQVFFQUFBQQ== >> >> Some gdb'ing shows that backglue copies over the pointers to >> rs->sr_ctrls >> into >> glue_state->ctrls. But then, back-ldap's ldap_back_search does a >> ldap_controls_free() on rs->sr_ctrls. And so, the returned control >> contains >> garbage (mostly). >> >> I haven't been able to come up with a patch yet, just commenting line >> 454 >> of >> back-ldap/search.c works. Running out of time for now... >> >> > > Probably, backglue should rather ldap_controls_dup() them. However, in > this case we need to make sure that the glued databases delete their own > copy. Also, I note that the glued paged response seems to work incorrectly. I made a simple test system, where the root database contains exactly one entry (the suffix) and a back-ldap is glued on top. If I request entries with a page size of 2, searching the suffix return 3 entries; subsequent searches return 2 entries from the proxy. I haven't figured out yet where the issue is. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> Full_Name: Jonathan Clarke > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.57.67.241) > > > This is similar to ITS #5191 (http://www.openldap.org/its/?findid=5191), > except > it happens with a subordinate LDAP database. > > Consider this configuration : > 8<--------------------------------------- > database ldap > suffix "o=test,o=sub" > uri "ldap://localhost:1234" > subordinate > idassert-bind mode=none bindmethod=simple flags=prescriptive timeout=0 > network-timeout=0 binddn="cn=svc,o=test" credentials="verysecret" > idassert-authzFrom dn.regex:.* > single-conn yes > > overlay rwm > rwm-suffixmassage "o=test,o=sub" "o=test" > > database null > suffix "o=sub" > rootdn "cn=Manager,o=sub" > rootpw secret > overlay glue > 8<--------------------------------------- > > A search with pagedResults control returns results as expected, but with a > response control containing some garbage: > > result: 0 Success > control:: > qOEpCDg0MC4xMTM1NTYuMS40LjMxOSBmYWxzZSBNSVFBQUFBSkFnRUFCQVFFQUFBQQ== > > Some gdb'ing shows that backglue copies over the pointers to rs->sr_ctrls > into > glue_state->ctrls. But then, back-ldap's ldap_back_search does a > ldap_controls_free() on rs->sr_ctrls. And so, the returned control > contains > garbage (mostly). > > I haven't been able to come up with a patch yet, just commenting line 454 > of > back-ldap/search.c works. Running out of time for now... > > Probably, backglue should rather ldap_controls_dup() them. However, in this case we need to make sure that the glued databases delete their own copy. p.

1 0

LDAP bind using ldap_sasl_interactive_bind_s and DIGEST-MD5 fails the second time
by James Bong 01 Apr '10

01 Apr '10

I am currently using Mac OS X 10.6.2 and am attempting to use the ldap_sasl_interactive_bind_s API to do a digest-md5 authentication against Active Directory (2008, though I don't think it matters what flavor of AD is used). The bind works fine the first time. However, if I unbind and attempt to rebind as the same user, it fails with ldap_sasl_interactive_bind_s: Invalid credentials (49). If I bind with a different user, then unbind, and bind as the original user, it works. I created a simple program that illustrates the issue. When run, it binds correctly, unbinds, and then fails on the second bind: trying ldap_sasl_interactive_bind_s callback callback done ldap_sasl_interactive_bind_s Done Unbinding Unbound. ldap_sasl_interactive_bind_s callback callback done ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0904D1, comment: AcceptSecurityContext error, data 57, v1772 Any idea why it is not possible to use the same credentials twice? Here is the test program. I tried reinitializing the sasl library with sasl_done and sasl_client_init, but that doesn't seem to make a difference. #include <ldap.h> #include <sasl/sasl.h> #include <stdio.h> typedef struct sasl_defaults { char *mech; char *realm; char *authcid; char *passwd; char *authzid; } sasl_defaults; int callback(LDAP *ld, unsigned flags, void* defaults, void *interact ) { printf("callback\n"); sasl_interact_t *in_out=(sasl_interact_t *)interact; sasl_defaults *in_defaults=(sasl_defaults *)defaults; while (in_out->id !=SASL_CB_LIST_END) { switch (in_out->id) { case SASL_CB_USER: in_out->result=in_defaults->authcid; in_out->len=strlen(in_defaults->authcid); break; case SASL_CB_AUTHNAME: in_out->result=in_defaults->authcid; in_out->len=strlen(in_defaults->authcid); break; case SASL_CB_PASS: in_out->result=in_defaults->passwd; in_out->len=strlen(in_defaults->passwd); break; case SASL_CB_GETREALM: in_out->result=""; in_out->len=strlen(""); break; } in_out++; } printf("callback done\n"); return 0; } int main (int argv, char ** argc) { printf("trying\n"); for (;;) { LDAP *ld; ldap_initialize(&ld, "ldap://dc.ad.domain.com:389"); ldap_set_option(ld,LDAP_OPT_REFERRALS,LDAP_OPT_OFF); int version=3; ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &version ); int timelimit=5; if (ldap_set_option( ld, LDAP_OPT_TIMELIMIT, (void *) &timelimit ) != LDAP_OPT_SUCCESS ) { printf("err\n"); return -1; } sasl_defaults defaults; defaults.mech = "DIGEST-MD5"; defaults.passwd="password"; defaults.authcid="user"; defaults.realm="realm.com"; defaults.authzid="user"; printf("ldap_sasl_interactive_bind_s\n"); int rc=ldap_sasl_interactive_bind_s( ld, NULL,defaults.mech, NULL, NULL, LDAP_SASL_QUIET, callback, &defaults ); if( rc != LDAP_SUCCESS ) { ldap_perror( ld, "ldap_sasl_interactive_bind_s" ); ldap_unbind(ld); return -1; } printf("ldap_sasl_interactive_bind_s Done\n"); printf("Unbinding\n"); ldap_unbind(ld); printf("Unbound.\n"); sleep(5); } }

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2010