- openldap-bugs - openldap.org

(ITS#5601) set-acl failure under back-ldap+rwm
by mbackes＠symas.com 07 Jul '08

07 Jul '08

Full_Name: Matthew Backes Version: 2.3, 2.4 OS: all URL: Submission from: (NULL) (76.88.99.93) Set-acl who-clauses fail to match when accessing data through back-ldap and slapo-rwm. Given a local server with only the object: dn: cn=data,dc=local objectClass: organizationalPerson cn: data sn: sn data description: user where sn is an example attribute that we will protect: database bdb suffix "cn=data,dc=local" directory ./local checkpoint 1024 1 cachesize 10 index objectClass,dc,entryCSN,entryUUID eq index cn,sn,ou,title,description eq,sub access to dn.subtree="cn=data,dc=local" attrs=sn by set="user/title & this/description" write by * none access to dn.subtree="cn=data,dc=local" by * read So that any bound object with a title attribute matching the description attribute of the target should be able to see sn. Remote data: dn: dc=remote objectClass: organization objectClass: dcObject o: remote dc: remote dn: cn=user,dc=remote objectClass: organizationalPerson cn: user sn: user title: user userPassword: secret If we have the local slapd's back-ldap configured as: database ldap suffix "dc=remote" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret then everything works correctly. But if we remap the DN using slapo-rwm instead: database ldap suffix "dc=remote,dc=local" uri "ldap://127.0.0.1:2389" acl-bind bindmethod=simple binddn="cn=user,dc=remote" credentials=secret overlay rwm rwm-suffixmassage "dc=remote,dc=local" "dc=remote" Then the acl step fails: => access_allowed: read access to "cn=data,dc=local" "sn" requested => dn: [1] cn=data,dc=local => acl_get: [1] matched => acl_get: [1] attr sn access_allowed: no res from state (sn) => acl_mask: access to entry "cn=data,dc=local", attr "sn" requested => acl_mask: to value by "cn=user,dc=remote", (=0) <= check a_set_pat: user/title & this/description <= check a_dn_pat: * <= acl_mask: [2] applying none(=0) (stop) <= acl_mask: [2] mask: none(=0) => access_allowed: read access denied by none(=0) send_search_entry: conn 1 access to attribute sn, value #0 not allowed And the remote server was never queried for the title attribute.

1 0

Re: (ITS#5600) syncrepl modify fails if superior objectClass added
by hyc＠symas.com 07 Jul '08

07 Jul '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux and solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl fails to update an entry if the objectClass was replaced > with a new set of values that explicitly lists a superior that > was only implicitly present in the old entry. > > I have only seen this during the present phase of replication, so > I don't know if it can happen during persistent update as well. > It probably worked for me in the persistent phase as the entire > entry was deleted and added again there. > > The patch at the end always uses replace instead of delete/add > of the objectClass values. Is this OK Howard? Or is it > necessary to perform further analysis of which values to > add/delete? It's probably OK. Doing specific add/delete is better from an indexing performance point of view. ... ITS#5517 is really starting to annoy me ... > > Rein Tollevik > Basefarm AS > > Index: syncrepl.c > =================================================================== > RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/syncrepl.c,v > retrieving revision 1.1.1.31 > diff -u -u -r1.1.1.31 syncrepl.c > --- syncrepl.c 6 Jul 2008 12:23:53 -0000 1.1.1.31 > +++ syncrepl.c 7 Jul 2008 19:21:57 -0000 > @@ -2883,6 +2883,14 @@ > } > } > > + /* Don't delete/add an objectClass, always use the replace op. > + * Modify would fail if provider has replaced entry with a new, > + * and the new explicitly includes a superior of a class that was > + * only included implicitly in the old entry. Ref ITS#5517. > + */ > + if ( nn&& no< o&& old->a_desc == slap_schema.si_ad_objectClass ) > + no = o; > + > i = j; > /* all old values were deleted, just use the replace op */ > if ( no == o ) { > > > -- -- 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#5600) syncrepl modify fails if superior objectClass added
by rein＠OpenLDAP.org 07 Jul '08

07 Jul '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Submitted by: rein Syncrepl fails to update an entry if the objectClass was replaced with a new set of values that explicitly lists a superior that was only implicitly present in the old entry. I have only seen this during the present phase of replication, so I don't know if it can happen during persistent update as well. It probably worked for me in the persistent phase as the entire entry was deleted and added again there. The patch at the end always uses replace instead of delete/add of the objectClass values. Is this OK Howard? Or is it necessary to perform further analysis of which values to add/delete? Rein Tollevik Basefarm AS Index: syncrepl.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/syncrepl.c,v retrieving revision 1.1.1.31 diff -u -u -r1.1.1.31 syncrepl.c --- syncrepl.c 6 Jul 2008 12:23:53 -0000 1.1.1.31 +++ syncrepl.c 7 Jul 2008 19:21:57 -0000 @@ -2883,6 +2883,14 @@ } } + /* Don't delete/add an objectClass, always use the replace op. + * Modify would fail if provider has replaced entry with a new, + * and the new explicitly includes a superior of a class that was + * only included implicitly in the old entry. Ref ITS#5517. + */ + if ( nn && no < o && old->a_desc == slap_schema.si_ad_objectClass ) + no = o; + i = j; /* all old values were deleted, just use the replace op */ if ( no == o ) {

1 0

Re: (ITS#5580) BER Decoding Remote DoS Vulnerability
by quanah＠zimbra.com 07 Jul '08

07 Jul '08

--On Friday, June 27, 2008 12:41 AM +0000 hyc(a)symas.com wrote: > Howard Chu wrote: >> zdi-disclosures(a)tippingpoint.com wrote: >>> Full_Name: Cameron Hotchkies >>> Version: 2.3.41 >>> OS: Gentoo Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (66.179.208.36) >>> >>> >>> This vulnerability allows remote attackers to deny services on >>> vulnerable installations of OpenLDAP. Authentication is not required to >>> exploit this vulnerability. >> >> Thanks for the report, a fix is now in HEAD. Please test. > > For future reference, it looks like this may have crept in in 2001, rev > 1.88/ITS#2465... 2003, not 2001? 1.88 Thu Apr 24 00:10:18 2003 UTC; 5 years, 2 months ago by hyc Changed since 1.87: +3 -3 lines Diffs to 1.87 (colored diff) ITS#2465 fix? ber_get_next must read at least sizeof(tag)+sizeof(len) which should be at most 8 bytes. However if we read more than the minimum message length, we have a problem because we steal bytes from any following message, and there is no buffer mechanism to push back excess data. The shortest legitimate message is Unbind at 7 bytes, but there shouldn't be anything following it. Abandon at 8 bytes is next, so always requesting at least 8 bytes should be safe. Always requesting 9 was a problem. Please double-check these assumptions... -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5355) back-meta calls back-ldap directly
by ando＠sys-net.it 07 Jul '08

07 Jul '08

rein(a)OpenLDAP.org wrote: > After fetching the recent CVS head today I started getting spurious > failures in test036-meta-concurrency, which appears to be related to the > mod* test programs failing with this message: > > Administrative limit exceeded (11) Operation timed out > > I assume that the new "idle-timeout" directive in > tests/data/slapd-meta.conf is the root of the failures. I'm currently > testing with the value increased from 10 to 100, but I don't know what > the best value would be. So far so good, but too early to conclude.. Yes. I have the same impression. In fact, removing idle-timeout seems to cure the occasional failures. I'll probably have a deeper look into it next weekend. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5593) Back-meta search references
by ando＠sys-net.it 07 Jul '08

07 Jul '08

andrew.graham(a)agustawestland.com wrote: > Please provide an option to stop search references being proxied from target to > client in back-meta. "norefs yes" added to HEAD (default "no"). Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5594) assertion thrown in daemon.c
by quanah＠zimbra.com 07 Jul '08

07 Jul '08

--On Thursday, July 03, 2008 5:43 PM +0000 richton(a)nbcs.rutgers.edu wrote: > This of course has ITS#5489 written all over it. If there is another RE23, > consider this a request to include the appropriate patch. Done. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5599) slapd dies on erroneous MOD input
by suomi＠ayni.com 07 Jul '08

07 Jul '08

Full_Name: suomi hasler Version: 2.4.8-3 OS: fedora 9 URL: http://www.ayni.com/slap-prob.txt Submission from: (NULL) (194.158.243.162) use perl-LDAP-0.34-4.fc9.noarch to communicate with the ldap server bind to the cn=config subtree in this configuration, change this entry: dn="olcDatabase={-1}frontend,cn=config" which is an olcAccess with the original value of: {10}to dn.subtree="ou=postfix,dc=mydom,dc=com" by dn.base="cn=myname,ou=pam-ldap,dc=mydom,dc=com" write by dn.base="cn=postfix,ou=postfix,dc=mydom,dc=com" read by self write by anonymous auth by users none to the following (erroneous) value (note the missing opening brace at the start) 10}to dn.subtree="ou=postfix,dc=mydom,dc=com" by dn.base="cn=myname,ou=pam-ldap,dc=mydom,dc=com" write by dn.base="cn=postfix,ou=postfix,dc=mydom,dc=com" read by self write by anonymous auth by users none on the interface you get: <snip> Modifying Attributes of DN: olcDatabase={-1}frontend,cn=config Modify-Result-Code: 80 Modify Attribute Error: ResultCode: 80, ErrorMessage: <olcAccess> handler exited with 1 Return Code from Modify Attribute: 80 Message: LDAP_OTHER: An unknown error has occurred MessageID: 4 </snip> some seconds later, slapd fails, that is, it does not reply to requests any more, and must be stopped using kill -9 pid. thereafter, the db is garbled but can be recovered by slapd -d255 -uldap after that you may start slapd using the normal procedures: /etc/init.d/ldap start reproduceability: always

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 06 Jul '08

06 Jul '08

Hi, On Tue, Jun 24, 2008 at 12:50 PM, Sean Burford <unix.gurus(a)gmail.com> wrote: > namingContexts was the trickiest, since RFC 4512 defines it without an > equality matching rule but monitor_back_register_database() compares > it with backend suffixes. It has to deal with capitalised values > properly otherwise we end up with duplicate namingContexts entries, so > normalization is required. I have uploaded ftp://ftp.openldap.org/incoming/sean-burford-monitor-test-080706.patch which adds a test for various things under cn=monitor. If duplicate namingContexts creep in (as mentioned above) it detects that. The duplicate naming contexts thing was fixed by comparing a_vals with be_suffix, I just wrote the test since there was no existing cn=monitor test. -- Thanks, Sean Burford

1 0

Re: (ITS#5540) Normalization assertion in attr.c
by unix.gurus＠gmail.com 06 Jul '08

06 Jul '08

Hi, On Sat, Jun 28, 2008 at 7:47 PM, Howard Chu <hyc(a)symas.com> wrote: > Howard Chu wrote: >> unix.gurus(a)gmail.com wrote: >>> If someone wants to accept or comment on what needs fixing in the >>> patch below, that would help me to generate the rest of the patches: >>> >>> ftp://ftp.openldap.org/incoming/sean-burford-monitor-normalize-unified-0806… >> >> In back-monitor/database.c you don't need to normalize the DNs before >> comparing them. The stored values are already Prettied, so all you need is >> to >> use a case-insensitive compare here. > > Duh. Or just compare a->a_vals and be->be_suffix instead. Good point. I've uploaded the following patch which does that as well as adding matching rules to configContext and monitorContext: ftp://ftp.openldap.org/sean-burford-monitor-normalize-unified-080706.patch This patch should make the handling of normalization within cn=monitor consistent. -- Thanks, Sean Burford

1 0

Re: (ITS#5572) Append global ACL to new backends
by hyc＠symas.com 06 Jul '08

06 Jul '08

rein(a)OpenLDAP.org wrote: > rein(a)OpenLDAP.org skrev: >> Howard Chu wrote: >>> rein(a)OpenLDAP.org wrote: >>>> The global ACLs are not added to newly created backends, i.e a server >>>> restart >>>> must be done before they are included. The patch at the end should >>>> fix this. OK >>>> to commit Howard? >>> My preference here would be to rip out everything that appends the >>> global ACLs and instead change the access_allowed checker to reference >>> the global ACLs directly when needed. >> Agreed, that would also fix the problem that dynamic updates to the >> global ACLs requires a restart to be effective. I can look into this >> next week. To be sure I have the semantics correct, it should be to >> evalutate ALCs local to the backend first, then the global, until a >> matching entry has been found? > > I have finally had time to look at this, and I have uploaded a > suggestion for a patch to ftp://ftp.openldap.org/incoming/ITS5572.patch, > > The AccessControlState cache and its backtracking was complicating > things a bit, but I hope I have got it correct. All the tests succeed > with the patch, although I'm not sure whether the cache is actually > tested or not.. This looks OK to me, but Ando should probably have a look as well. > I haven't done anything with the code that avoids messing with the > global ACL part when modifications are done to a backend ACL, it will > simply not find any trailing frontend ACL to stay away from. I'll remove that code after this is committed. > There is a probably a similar problem in the pcache and translucent > overlays, as they makes a copy of the backend ACL when initializing. > I.e changes to the backend ACL would not be noticed until a restart? I > haven't look any further into this, but a bi_access_allowed function > that dynamically fetches the be_acl from the backend could be a fix. Hm... Have to re-think how this is handled. There are other backend parameters being copied as well. -- -- 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#5572) Append global ACL to new backends
by rein＠OpenLDAP.org 06 Jul '08

06 Jul '08

rein(a)OpenLDAP.org skrev: > Howard Chu wrote: >> rein(a)OpenLDAP.org wrote: >>> The global ACLs are not added to newly created backends, i.e a server >>> restart >>> must be done before they are included. The patch at the end should >>> fix this. OK >>> to commit Howard? >> My preference here would be to rip out everything that appends the >> global ACLs and instead change the access_allowed checker to reference >> the global ACLs directly when needed. > > Agreed, that would also fix the problem that dynamic updates to the > global ACLs requires a restart to be effective. I can look into this > next week. To be sure I have the semantics correct, it should be to > evalutate ALCs local to the backend first, then the global, until a > matching entry has been found? I have finally had time to look at this, and I have uploaded a suggestion for a patch to ftp://ftp.openldap.org/incoming/ITS5572.patch, The AccessControlState cache and its backtracking was complicating things a bit, but I hope I have got it correct. All the tests succeed with the patch, although I'm not sure whether the cache is actually tested or not.. I haven't done anything with the code that avoids messing with the global ACL part when modifications are done to a backend ACL, it will simply not find any trailing frontend ACL to stay away from. There is a probably a similar problem in the pcache and translucent overlays, as they makes a copy of the backend ACL when initializing. I.e changes to the backend ACL would not be noticed until a restart? I haven't look any further into this, but a bi_access_allowed function that dynamically fetches the be_acl from the backend could be a fix. Rein

1 0

Re: (ITS#5578) sortvals error
by hyc＠symas.com 05 Jul '08

05 Jul '08

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.10 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/andrew-findlay-20080625.tgz > Submission from: (NULL) (88.97.25.132) > > > When 'sortvals members' is in effect, some attribute modify operations produce > bad results. This seems to occur when an operation adds an attribute that sorts > to the end of the list. > > The attached tarball contains a cut-down config and dataset, along with a set of > scripts and LDIF files that demonstrate the bug. Thanks for the report. Seems the search routine wasn't copied correctly from back-bdb/idl.c. Fixed now in HEAD. -- -- 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#5598) issue 4068, test018-syncreplication-persist failed
by dimytch＠mail.ru 05 Jul '08

05 Jul '08

Full_Name: Dimitri Pekarovsky Version: 2.4.10 OS: Slackware Linux 12.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.26.128.251) logs and other (possibly) useful info are there: wisdom.org.ua/config.log.bz2 (23 KB) wisdom.org.ua/config.status.bz2 (16 KB) wisdom.org.ua/openldap-2.4.10-compiled-failed_test_018.tar.bz2 (9.1 MB) full dir More shortly: $ uname -a Linux fserv 2.6.24.4 #13 SMP Fri Mar 28 20:53:03 EET 2008 i686 Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz GenuineIntel GNU/Linux $ ./configure --prefix=/opt/ldap --sysconfdir=/etc --localstatedir=/var/ldap --disable-ipv6 --enable-syslog --enable-slapd --enable-cleartext --enable-crypt --enable-lmpasswd --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups --enable-slapi --enable-wrappers --enable-bdb=mod --enable-dnssrv=mod --enable-hdb=mod --enable-ldap=mod --enable-monitor=mod --enable-passwd=mod --enable-perl=mod --enable-relay=mod --enable-sock=mod --enable-overlays=mod --with-cyrus-sasl --with-threads --with-tls=openssl --enable-syncprov=mod --enable-seqmod=mod && make depend && make && make test ======VARIABLES $ echo $CFLAGS -msse2 -mcpu=pentium4 -mtune=pentium4 -pipe -I/opt/db/include -I/opt/ldap/include -I/opt/pgsql/include -I/opt/apache/include -I/opt/pgsql/include -I/opt/svn/include -L/opt/db/lib -L/opt/ldap/lib -L/opt/pgsql/lib -L/opt/pgsql/lib -L/opt/apache/lib -L/opt/svn/lib $ echo $CPPFLAGS -I/opt/db/include -I/opt/ldap/include -I/opt/pgsql/include -I/opt/apache/include -I/opt/pgsql/include -I/opt/svn/include $ echo $LDFLAGS -L/opt/db/lib -L/opt/ldap/lib -L/opt/pgsql/lib -L/opt/pgsql/lib -L/opt/apache/lib -L/opt/svn/lib .... Berkley DB 4.6.21 ....ERROR MESSAGE >>>>> Starting test018-syncreplication-persist ... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entry in the producer... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that producer slapd is running... Using ldapmodify to modify producer directory... Using ldappasswd to change some passwords... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the consumer slapd... ldapmodify failed (255)! ./scripts/test018-syncreplication-persist: line 309: kill: (12453) - Нет такого процесса -- NO SUCH PROCESS (TRANSLATION ADDED BY HAND) >>>>> ./scripts/test018-syncreplication-persist failed (exit 255) make[2]: *** [bdb-mod] Ошибка 255 make[2]: Leaving directory `/usr/src/i/openldap-2.4.10/tests' make[1]: *** [test] Ошибка 2 make[1]: Leaving directory `/usr/src/i/openldap-2.4.10/tests' make: *** [test] Ошибка 2

1 0

Re: (ITS#5597) syncrepl can fail to compare CSN from provider
by hyc＠symas.com 04 Jul '08

04 Jul '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux, solaris > URL: > Submission from: (NULL) (84.215.36.97) > Submitted by: rein > > > If the syncrepl provider presents the same (or a lower) number of contextCSN > values than the consumer has, but with other sid values, it can fail to update > its values. > This is mostly seen in a multiple masters (as opposed to a multi-master) > configuration. > > The patch at the end should fix that. Does it look OK Howard? Yes, looks fine, go ahead and commit. > > Rein Tollevik > Basefarm AS > > Index: syncrepl.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/syncrepl.c,v > retrieving revision 1.405 > diff -u -u -r1.405 syncrepl.c > --- syncrepl.c 4 Jul 2008 21:44:39 -0000 1.405 > +++ syncrepl.c 4 Jul 2008 21:48:13 -0000 > @@ -689,8 +689,8 @@ > return -1; > } > > - for (i=0; i<sc1->numcsns; i++) { > - for (j=0; j<sc2->numcsns; j++) { > + for (j=0; j<sc2->numcsns; j++) { > + for (i=0; i<sc1->numcsns; i++) { > if ( sc1->sids[i] != sc2->sids[j] ) > continue; > value_match(&match, slap_schema.si_ad_entryCSN, > @@ -703,6 +703,11 @@ > } > break; > } > + if ( i == sc1->numcsns ) { > + /* sc2 has a sid sc1 lacks */ > + *which = j; > + return -1; > + } > } > return match; > } > > > -- -- 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#5597) syncrepl can fail to compare CSN from provider
by rein＠OpenLDAP.org 04 Jul '08

04 Jul '08

Full_Name: Rein Tollevik Version: CVS head OS: linux, solaris URL: Submission from: (NULL) (84.215.36.97) Submitted by: rein If the syncrepl provider presents the same (or a lower) number of contextCSN values than the consumer has, but with other sid values, it can fail to update its values. This is mostly seen in a multiple masters (as opposed to a multi-master) configuration. The patch at the end should fix that. Does it look OK Howard? Rein Tollevik Basefarm AS Index: syncrepl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/syncrepl.c,v retrieving revision 1.405 diff -u -u -r1.405 syncrepl.c --- syncrepl.c 4 Jul 2008 21:44:39 -0000 1.405 +++ syncrepl.c 4 Jul 2008 21:48:13 -0000 @@ -689,8 +689,8 @@ return -1; } - for (i=0; i<sc1->numcsns; i++) { - for (j=0; j<sc2->numcsns; j++) { + for (j=0; j<sc2->numcsns; j++) { + for (i=0; i<sc1->numcsns; i++) { if ( sc1->sids[i] != sc2->sids[j] ) continue; value_match( &match, slap_schema.si_ad_entryCSN, @@ -703,6 +703,11 @@ } break; } + if ( i == sc1->numcsns ) { + /* sc2 has a sid sc1 lacks */ + *which = j; + return -1; + } } return match; }

1 0

Re: (ITS#5595) bdb deadlock if add causes modify
by hyc＠symas.com 04 Jul '08

04 Jul '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux and solaris > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > A deadlock occur in bdb_cache_modify() when it calls bdb_cache_entry_db_relock() > if adding an entry triggers a modify of the same entry. Seen by adding the > suffix entry of a backend with the syncprov overlay and syncprov-checkpoint set > to "1 1", i.e the add causes syncprov_checkpoint() to be called. > The problem is that bdb_add() calls send_ldap_result() while the entry is > locked. But I'm not sure whether releasing the entry before it is done is > correct or not. Nor if this should be considered a usage bug in the first > place... Yes, known issue, don't do this. -- -- 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#5596) contextCSN updates are internal operations
by hyc＠symas.com 04 Jul '08

04 Jul '08

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS head > OS: linux, solaris > URL: > Submission from: (NULL) (84.215.36.97) > Submitted by: rein > > > syncrepl_updateCookie() doesn't initialize mod.sml_flags, which means that the > contextCSN modification is done with a random value. Which again can cause the > modify to fail if syncrepl is used on a subordinate DB with another rootdn than > what the glue DB has. As documented, glued DBs must all have the same rootDN. Any other configuration is a user error. > syncprov_checkpoint() has a similar problem, it initializes mod.sml_flags to 0. > When a checkpoint occur the modify operation is run with the privileges of what > might be in op->o_ndn. Checkpoint when the database is closed always works > though, as op->o_ndn is always set to the rootdn when that is done. > I'll commit a fix that sets mod.sml_flags to SLAP_MOD_INTERNAL shortly, so that > access control rules are bypassed. > > Rein Tollevik > Basefarm AS -- -- 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#5596) contextCSN updates are internal operations
by rein＠OpenLDAP.org 04 Jul '08

04 Jul '08

Full_Name: Rein Tollevik Version: CVS head OS: linux, solaris URL: Submission from: (NULL) (84.215.36.97) Submitted by: rein syncrepl_updateCookie() doesn't initialize mod.sml_flags, which means that the contextCSN modification is done with a random value. Which again can cause the modify to fail if syncrepl is used on a subordinate DB with another rootdn than what the glue DB has. syncprov_checkpoint() has a similar problem, it initializes mod.sml_flags to 0. When a checkpoint occur the modify operation is run with the privileges of what might be in op->o_ndn. Checkpoint when the database is closed always works though, as op->o_ndn is always set to the rootdn when that is done. I'll commit a fix that sets mod.sml_flags to SLAP_MOD_INTERNAL shortly, so that access control rules are bypassed. Rein Tollevik Basefarm AS

1 0

Re: (ITS#5355) back-meta calls back-ldap directly
by rein＠OpenLDAP.org 04 Jul '08

04 Jul '08

After fetching the recent CVS head today I started getting spurious failures in test036-meta-concurrency, which appears to be related to the mod* test programs failing with this message: Administrative limit exceeded (11) Operation timed out I assume that the new "idle-timeout" directive in tests/data/slapd-meta.conf is the root of the failures. I'm currently testing with the value increased from 10 to 100, but I don't know what the best value would be. So far so good, but too early to conclude.. Rein

1 0

(ITS#5595) bdb deadlock if add causes modify
by rein＠OpenLDAP.org 04 Jul '08

04 Jul '08

Full_Name: Rein Tollevik Version: CVS head OS: linux and solaris URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein A deadlock occur in bdb_cache_modify() when it calls bdb_cache_entry_db_relock() if adding an entry triggers a modify of the same entry. Seen by adding the suffix entry of a backend with the syncprov overlay and syncprov-checkpoint set to "1 1", i.e the add causes syncprov_checkpoint() to be called. The problem is that bdb_add() calls send_ldap_result() while the entry is locked. But I'm not sure whether releasing the entry before it is done is correct or not. Nor if this should be considered a usage bug in the first place... Rein Tollevik Basefarm AS

1 0

(ITS#5594) assertion thrown in daemon.c
by richton＠nbcs.rutgers.edu 03 Jul '08

03 Jul '08

Full_Name: Aaron Richton Version: 2.3.41 OS: Solaris 9 URL: http://www.openldap.org/its/index.cgi/Software Bugs?id=5489 Submission from: (NULL) (128.6.31.135) 2.3.41 died on one of my slaves: Current function is slapd_clr_write 813 assert( SLAP_SOCK_IS_ACTIVE( s )); (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0xffffffffffffffe6, 0x0, 0x0, 0x0), at 0xffffffff7f0a8d4c [2] raise(0x6, 0x0, 0xffffffff517fd810, 0x0, 0x0, 0x0), at 0xffffffff7f058dc0 [3] abort(0x44, 0x0, 0x44, 0x7efefeff, 0x81010100, 0xff0000), at 0xffffffff7f03e688 [4] __assert(0x1002394d8, 0x1002394f8, 0x32d, 0xffffffff517fca10, 0x1003afb60, 0x5), at 0xffffffff7f03e98c =>[5] slapd_clr_write(s = 180, wake = 0), line 813 in "daemon.c" [6] connection_write(s = 180), line 1905 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2329 in "daemon.c" The last log message related to this was: conn=65083139 fd=180 closed (connection lost on write) This of course has ITS#5489 written all over it. If there is another RE23, consider this a request to include the appropriate patch.

1 0

ldapsearch and buffered stdout
by Dale.Moore＠cs.cmu.edu 03 Jul '08

03 Jul '08

The client tool can read from stdin and produce output on stdout. For example ldapsearch -L -x -f - 'cn=%s' uid This will read cn values from stdin and produce search results on stdout. But doing this interactively does not produce the immediate feedback because stdout is often buffered. The search results are presented only after a sufficient amount have been buffered, or an EOF is encountered. It would be very nice if ldapsearch application would flush stdout after each search. Below is a diff of the ldapsearch client tool with my proposed change. *************** *** 1,5 **** /* ldapsearch -- a tool for searching LDAP directories */ ! /* $OpenLDAP: pkg/ldap/clients/tools/ldapsearch.c,v 1.234.2.9 2008/02/12 19:59:52 quanah Exp $ */ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 1998-2008 The OpenLDAP Foundation. --- 1,5 ---- /* ldapsearch -- a tool for searching LDAP directories */ ! /* $OpenLDAP: pkg/ldap/clients/tools/ldapsearch.c,v 1.234.2.9 2008/02/12 19:59:52 quanah Exp $ */ /* This work is part of OpenLDAP Software <http://www.openldap.org/>. * * Copyright 1998-2008 The OpenLDAP Foundation. *************** *** 998,1003 **** --- 998,1004 ---- if ( !contoper ) break; } + fflush(stdout); } if ( fp != stdin ) { fclose( fp );

3 2

(ITS#5593) Back-meta search references
by andrew.graham＠agustawestland.com 03 Jul '08

03 Jul '08

Full_Name: Andrew Graham Version: 2.4.10 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.169.32.250) Please provide an option to stop search references being proxied from target to client in back-meta.

1 0

(ITS#5592) Quarantine in back-meta
by andrew.graham＠agustawestland.com 03 Jul '08

03 Jul '08

Full_Name: Andrew Graham Version: 2.4.10 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.169.32.250) The quarantine function in back-meta will permanently disable a target if a query is received while the quarantine has been imposed. To reproduce, use the config file below. Send a query and the quarantine will be set. Send another query within 20 seconds and the quarantine will not lift without restarting slapd. ---- slapd.conf ---- include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args database meta suffix dc=example,dc=com uri ldap://afakeaddress/dc=target,dc=example,dc=com quarantine 20,+

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs