openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

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 07 Jul '08

07 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 07 Jul '08

07 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 05 Jul '08

05 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

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