openldap-bugs

openldap-bugs@openldap.org

1 participants
21509 discussions

Re: (ITS#5569) smbk5pwd breaks ppolicy-mandated password changes
by hyc＠symas.com 08 Jul '08

08 Jul '08

This is a multi-part message in MIME format. --------------020700010705000602080304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: 2.3.41 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.207.32.38) > I have not run this same test case on 2.4.x yet, but I remember having problems > trying to change passwords on 2.4.10 with a very similar configuration, so I > think it exists in 2.4.10 as well. Please try this patch... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------020700010705000602080304 Content-Type: text/plain; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dif.txt" Index: ppolicy.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/ppolicy.c,v retrieving revision 1.115 diff -u -r1.115 ppolicy.c --- ppolicy.c 12 Jun 2008 19:12:35 -0000 1.115 +++ ppolicy.c 8 Jul 2008 09:55:17 -0000 @@ -1401,7 +1401,7 @@ Attribute *pa, *ha, at; const char *txt; pw_hist *tl = NULL, *p; - int zapReset, send_ctrl = 0; + int zapReset, send_ctrl = 0, pwexop = 0; Entry *e; struct berval newpw = BER_BVNULL, oldpw = BER_BVNULL, *bv, cr[2]; @@ -1526,6 +1526,7 @@ req_pwdexop_s *qpw = sc->sc_private; newpw = qpw->rs_new; oldpw = qpw->rs_old; + pwexop = 1; break; } } @@ -1581,7 +1582,7 @@ } } - } else if ( !is_at_operational( ml->sml_desc->ad_type ) ) { + } else if ( !pwexop && !is_at_operational( ml->sml_desc->ad_type ) ) { mod_pw_only = 0; /* modifying something other than password */ } --------------020700010705000602080304--

1 0

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

07 Jul '08

Further to my report, i found the following in the syslog of when slapd had failed: Jul 7 07:05:31 myhost kernel: slapd[23962]: segfault at 0 ip 004cb118 sp b2b7c55c error 4 in libc-2.8.so[456000+163000] -- ---------------------------------------- Ayni AG Sternenstrasse 24 P.O.Box 1521 CH-8027 Zurich Switzerland, Europe +41 44 280 22 44, Fax +41 44 280 22 49 E-mail: nospam(a)ayni.com Web: http://www.ayni.com

1 0

(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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs