openldap-bugs July 2008

openldap-bugs@openldap.org

43 participants
131 discussions

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

← Newer
1
...
7
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2008