openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

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