openldap-bugs

openldap-bugs@openldap.org

1 participants
21518 discussions

Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com 18 Aug '15

18 Aug '15

--cDyoBSpeMmeqjtIY Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 17, 2015 at 05:35:11PM -0700, Ryan Tandy wrote: >Hi Zach, > >I just pushed a patch for another ITS that reminded me of this one. > >Assuming you can still reproduce this, would you please try the patch=20 >mentioned at the end of http://www.openldap.org/its/?findid=3D8199 and=20 >let us know whether it resolves your crash? I've upgraded to 2.4.41.1 from the LTB packages an no longer have the=20 issue. --=20 Zach Leslie :: Puppet Labs --cDyoBSpeMmeqjtIY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAABCgAGBQJV02IGAAoJEH5UaJShK/iwqlwH/2Dc1xZor0I4of/4wWKN/o/y 73ZrwM/jsYsGez9jxU2t4gIhDfSBx38hqBFj801hGmF0Ef3xY8fDTlv7nEhXZ30J CEk2zQ4py0aBJG6kAe8sfZdmS8SPS6o2FzNoCR4w833oj11qYMIUbJLHzLsA6LWg STCcBapBIf0iHSfDBlwN3w93C5UXp71pWLAJEqcfSCtxhCCpAJr3WdndLjboN89c YVKl5NzDTmgInHmne4Ob+QFCN1nNw5z1uE2tkhV0FAw3QpVZsnDXIVW9Gjmr835c +UfQHqErY5PstxHY1V42h6CyX8IDby3rB5NuR31H/8uI0ToNaQry5EX40ZCvaa4= =BGFe -----END PGP SIGNATURE----- --cDyoBSpeMmeqjtIY--

1 0

(ITS#8173)
by Adrian.Raemy＠vtg.admin.ch 18 Aug '15

18 Aug '15

Dear Howard, The fix runs stable now over weeks.=20 slapd didn't crashed anymore. Thank you for the help. I guess we can close the ticket. Best Regards Adrian=20

1 0

Re: (ITS#8212) slapd stops on consumer node
by ryan＠openldap.org 14 Aug '15

14 Aug '15

Hi, I experimented with openldap 2.4.41 and the files you posted and did not experience any crashes. Please try to reduce the example setup as far as possible, until you find that the crash disappears after you disable a particular directive. Please also make sure you have the debugging symbols for slapd and libldap installed, and then try to provide a backtrace from gdb after triggering the crash, as well as the exact config files (and, if possible, relevant DIT contents, such as ppolicy configuration) that were in use at the time. Thanks for your help, Ryan

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 14 Aug '15

14 Aug '15

On 08/14/2015 10:38 AM, Howard Chu wrote: > subbarao(a)computer.org wrote: >> In the particular situation that's prompting this request, it's not just >> two or three values -- for one entry it was over 38000 values that had >> accumulated over time! (and generally high values for many other >> entries). > > If you have entries with tens of thousands of Bind failures being > recorded, you have a security monitoring problem. The limit applied by > the patch for this ITS will only mask the problem. The fact that your > security auditors haven't already noticed these tens of thousands of > Bind failures and stopped them at their source means you've got a > major vulnerability in your network security. Hi Howard, what's happening here is that an application account's password has expired, and its owners have neglected to change the password. Meanwhile, the old password remains hardcoded in the application, which continues to issue BIND requests that fail. The functionality of this particular application isn't mission-critical -- it may even be deprecated at this point by another application, so it's likely not a priority for the account owners given everything else on their plates. In this customer environment, the monitoring of password failures has historically been done outside of LDAP, and focuses on user accounts which tend to have higher privileges. LDAP application accounts (which tend to have minimal privileges) aren't treated the same. These bind failures may get cleaned up at some point during a periodic review of application accounts with expired passwords, but it's not likely to happen soon, given the lower level of risk/impact. Given that the bind failures themselves aren't causing a problem (the system as a whole has ample capacity), the only operations-impacting issue is the continually increasing entry size. So for this customer environment, I feel the best approach for now is to simply purge the stale failure timestamps (which I would prefer to do with a standard OpenLDAP configuration setting than with an external script). As I mentioned in an earlier message, I see the slapo-ppolicy man page as being friendly to this feature request: "Excess timestamps beyond those allowed by pwdMaxFailure may also be purged." From my perspective, it's a valuable hygienic feature for environments such as this one. Regards, -Kartik

1 0

Re: (ITS#8133) segfault at startup with memberof+dds
by ryan＠nardis.ca 14 Aug '15

14 Aug '15

Hi, On Wed, May 06, 2015 at 05:48:53PM +0000, alexoz66(a)gmail.com wrote: >When those two overlays are configured in this order: {0}memberof, {1}dds, slapd >will segfault at startup if dds finds a dynamicObject entry that is past its >expiration time. This does not occur if an object expires while slapd is >running, only during startup. A patch for this is in git master now. Please test it. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=1c4942413… thanks, Ryan

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by hyc＠symas.com 14 Aug '15

14 Aug '15

subbarao(a)computer.org wrote: > In the particular situation that's prompting this request, it's not just > two or three values -- for one entry it was over 38000 values that had > accumulated over time! (and generally high values for many other entries). If you have entries with tens of thousands of Bind failures being recorded, you have a security monitoring problem. The limit applied by the patch for this ITS will only mask the problem. The fact that your security auditors haven't already noticed these tens of thousands of Bind failures and stopped them at their source means you've got a major vulnerability in your network security. -- -- 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#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by hyc＠symas.com 14 Aug '15

14 Aug '15

subbarao(a)computer.org wrote: > On 07/06/2015 01:30 PM, Michael Ströder wrote: >> Consider that you are under on-going attack with many different >> accounts affected by the lockout treshold. Then you cannot simply wait >> for pwdFailureCountInterval seconds because your system is changing >> all the time. >> >> Such a situation is a real world scenario. > > Ok -- I'm probably not understanding enough about your particular > scenario to fully appreciate the concerns that you express. But I think > there could be ways to address them in this enhancement -- for instance, > by adding optional parameter(s) like ppolicy_purge_failures <nfailures> > and/or ppolicy_purge_olderthan <timestamp>, which could then be > configured to accommodate the scenario you describe. > > At this point, I'll think I'll leave it up to the OpenLDAP developers as > to how they want to proceed on this, and/or to ask for more information. I've added a pwdMaxRecordedFailure attribute to the policy schema. Overloading pwdMaxFailure would be a mistake. MaxRecordedFailure will default to MaxFailure if that is set. It defaults to 5 if nothing is set. There's no good reason to allow the timestamps to accumulate without bound. This is now available for testing in git master. -- -- 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#8217) Add msvc support to lmdb
by nacho.resa＠gmail.com 13 Aug '15

13 Aug '15

Full_Name: Ignacio Casal Quinteiro Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.30.165.68) On the url below you can find a fork that adds support for msvc builds: https://github.com/nice-software/lmdb/tree/wip/msvc https://github.com/nice-software/lmdb/commit/e871e736949dafee4e84f07c6cfb1b…

1 0

(ITS#8216) Windows 'make test' failures
by mhardin＠symas.com 11 Aug '15

11 Aug '15

Full_Name: Matthew Hardin Version: 2.4.40 OS: Windows 7/64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.43.206.100) Many 'make test' test fail, for a variety of reasons, with LMDB and BDB/HDB backends. OpenLDAP 2.4.40 Berkeley DB 4.8.30 Environment: MSYS from MinGW/MSYS 2013072300 Win-Builds MinGW 32- and 64-bit toolchain The following tests fail: test0-c-concurrency: problems reported by slapd-tester test039-glue-ldap-concurrency: seems to fail for the same reasons as test008 test043-delta-syncrepl: lmdb always fails, hdb/bdb sometimes test049-sync-config: config parsing problems test050-syncrepl-multimaster: config parsing problems test056-monitor: incorrect monitor output test058-syncrepl-asymmetric: parsing problems test059-slave-config: parsing problems test061-syncreplication-initiation: parsing prlelems test063-delta-multimaster: undetermined test064-constraint: include file processing (parsing?)

1 0

(ITS#8215) Slapmodify delete support and documentation
by ondra＠mistotebe.net 11 Aug '15

11 Aug '15

Full_Name: Ond&#345;ej Kuzn.k Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150811-slapmodify-delete-su… Submission from: (NULL) (62.84.155.99) It is only possible to delete entries in a back-ldif database. This patchset implements the equivalent functionality in the other core databases, enables the same in back-config and adds a slapmodify manpage. With that in place, test007-slapmodify is switched to fail on errors now. ModRDN stays unimplemented at this point. An outstanding issue is that valgrind complains about a memory leak in bdb on entry delete, which I have not been able to pinpoint nor fix. The above patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the above patches were developed by Ondřej Kuzník <ondra(a)mistotebe.net>. I have not assigned rights and/or interest in this work to any party. I, Ondřej Kuzník, hereby place the above modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

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