openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

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

(ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by jonathan＠phillipoux.net 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...

1 0

RE: (ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by bcolston＠xtec.com 01 Apr '10

01 Apr '10

Provider slapd configuration (partial): serverID 000 database bdb suffix "dc=authentx" rootdn "SUPPRESSED" rootpw SUPPRESSED directory /authentx/db/ldap/authentx-sync1 overlay syncprov syncprov-checkpoint 100 15 syncprov-sessionlog 5000 checkpoint 128 20 index objectClass eq,pres index entryCSN,entryUUID eq cachesize 100000 dncachesize 200000 idlcachesize 1000 sizelimit 500000 timelimit 36000 Consumer slapd configuration (partial): serverID 001 database bdb suffix "dc=authentx" rootdn "SUPPRESSED" rootpw SUPPRESSED directory /authentx/db/ldap/authentx-sync2 syncrepl rid=001 provider=ldap://localhost:3891 type=refreshAndPersist retry="300 60 60 +" searchbase="dc=authentx" scope=sub schemachecking=off bindmethod=simple binddn="SUPPRESSED" credentials="SUPPRESSED" checkpoint 128 20 index objectClass eq,pres index entryCSN,entryUUID eq cachesize 100000 dncachesize 200000 idlcachesize 1000 sizelimit 500000 timelimit 36000 Barry -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Wednesday, March 31, 2010 9:17 PM To: bcolston(a)xtec.com Cc: openldap-its(a)openldap.org Subject: Re: (ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started bcolston(a)xtec.com wrote: > Full_Name: Barry Colston > Version: 2.4.21 > OS: Fedora 12 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.255.208.210) > > > When a consumer slapd is started, if the provider slapd has had only Add > operations performed while the consumer slapd was down, the provider slapd sends > the consumer slapd the entryUUIDs of all records in the provider database. > Note: this is not a list of all records that have been added/changed/deleted > since the previous synchronization based on the consumer's contextCSN, it is a > list of all records in the LDAP database (for some of our customers, this is > 10,000,000 entryUUIDs that are returned to the consumer slapd.) That is the normal behavior of syncrepl. Read the Admin Guide and/or RFC4533. > The scenario to reproduce this problem is: > 1. Start provider slapd > 2. Start consumer slapd > 3. Ensure that provider contextCSN matches consumer contextCSN > 4. Shutdown consumer slapd > 5. Add records to provider slapd (1 record is sufficient to create the problem) > 6. Start consumer slapd with debug turned on (so the messages being sent can be > viewed). The consumer slapd receives 1 to N LDAP_RES_INTERMEDIATE SYNC_ID_SETs > (message type = 121) containing the entryUUIDs of the records in the provider's > database, followed by a LDAP_RES_SEARCH_ENTRY, LDAP_SYNC_ADD (message type = > 100) message for each record added to the provider, then finally a > LDAP_RES_INTERMEDIATE, REFRESH_PRESENT message (message type = 121) message > containing the provider's sync cookie. > > I am running OpenLDAP 2.4.21 with Berkeley 4.6.21 (with all patches) on Fedora > 12. Running sync replication in RefreshAndPersist mode. > > Note: if at least 1 Modify or Delete operation is performed against the provider > slapd while the consumer slapd is down, when the consumer slapd is started, the > provider slapd does NOT send the Sync ID sets containing the entryUUIDs of all > records in the provider database. Using the syncprov_sessionlog can allow the provider to shortcut this. Since you haven't show any details of your configuration, we can't say if this difference in behavior is a bug or a config error. -- -- 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#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by hyc＠symas.com 31 Mar '10

31 Mar '10

bcolston(a)xtec.com wrote: > Full_Name: Barry Colston > Version: 2.4.21 > OS: Fedora 12 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.255.208.210) > > > When a consumer slapd is started, if the provider slapd has had only Add > operations performed while the consumer slapd was down, the provider slapd sends > the consumer slapd the entryUUIDs of all records in the provider database. > Note: this is not a list of all records that have been added/changed/deleted > since the previous synchronization based on the consumer's contextCSN, it is a > list of all records in the LDAP database (for some of our customers, this is > 10,000,000 entryUUIDs that are returned to the consumer slapd.) That is the normal behavior of syncrepl. Read the Admin Guide and/or RFC4533. > The scenario to reproduce this problem is: > 1. Start provider slapd > 2. Start consumer slapd > 3. Ensure that provider contextCSN matches consumer contextCSN > 4. Shutdown consumer slapd > 5. Add records to provider slapd (1 record is sufficient to create the problem) > 6. Start consumer slapd with debug turned on (so the messages being sent can be > viewed). The consumer slapd receives 1 to N LDAP_RES_INTERMEDIATE SYNC_ID_SETs > (message type = 121) containing the entryUUIDs of the records in the provider's > database, followed by a LDAP_RES_SEARCH_ENTRY, LDAP_SYNC_ADD (message type = > 100) message for each record added to the provider, then finally a > LDAP_RES_INTERMEDIATE, REFRESH_PRESENT message (message type = 121) message > containing the provider's sync cookie. > > I am running OpenLDAP 2.4.21 with Berkeley 4.6.21 (with all patches) on Fedora > 12. Running sync replication in RefreshAndPersist mode. > > Note: if at least 1 Modify or Delete operation is performed against the provider > slapd while the consumer slapd is down, when the consumer slapd is started, the > provider slapd does NOT send the Sync ID sets containing the entryUUIDs of all > records in the provider database. Using the syncprov_sessionlog can allow the provider to shortcut this. Since you haven't show any details of your configuration, we can't say if this difference in behavior is a bug or a config error. -- -- 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

(ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by bcolston＠xtec.com 31 Mar '10

31 Mar '10

Full_Name: Barry Colston Version: 2.4.21 OS: Fedora 12 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.255.208.210) When a consumer slapd is started, if the provider slapd has had only Add operations performed while the consumer slapd was down, the provider slapd sends the consumer slapd the entryUUIDs of all records in the provider database. Note: this is not a list of all records that have been added/changed/deleted since the previous synchronization based on the consumer's contextCSN, it is a list of all records in the LDAP database (for some of our customers, this is 10,000,000 entryUUIDs that are returned to the consumer slapd.) The scenario to reproduce this problem is: 1. Start provider slapd 2. Start consumer slapd 3. Ensure that provider contextCSN matches consumer contextCSN 4. Shutdown consumer slapd 5. Add records to provider slapd (1 record is sufficient to create the problem) 6. Start consumer slapd with debug turned on (so the messages being sent can be viewed). The consumer slapd receives 1 to N LDAP_RES_INTERMEDIATE SYNC_ID_SETs (message type = 121) containing the entryUUIDs of the records in the provider's database, followed by a LDAP_RES_SEARCH_ENTRY, LDAP_SYNC_ADD (message type = 100) message for each record added to the provider, then finally a LDAP_RES_INTERMEDIATE, REFRESH_PRESENT message (message type = 121) message containing the provider's sync cookie. I am running OpenLDAP 2.4.21 with Berkeley 4.6.21 (with all patches) on Fedora 12. Running sync replication in RefreshAndPersist mode. Note: if at least 1 Modify or Delete operation is performed against the provider slapd while the consumer slapd is down, when the consumer slapd is started, the provider slapd does NOT send the Sync ID sets containing the entryUUIDs of all records in the provider database.

1 0

Re: (ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by crispy＠cluenet.org 31 Mar '10

31 Mar '10

Hi, any word on if this can be incorporated? Thanks. On Sun, 2010-03-07 at 01:24 +0000, openldap-its(a)OpenLDAP.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6488. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6488) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6488) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6488 > > Please remember to retain your issue tracking number (ITS#6488) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >

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