openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#6641) Syncrepl failure with 'overlay unique'
by ondrej.kuznik＠acision.com 06 May '11

06 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/21/2011 04:11 AM, hyc(a)symas.com wrote: > ondrej.kuznik(a)acision.com wrote: >> After a conversation with Howard, I have modified the patches so that >> the overlay check for the ManageDsaIt control instead. That control >> should be set for each operation coming from replication. The patches >> are here: >> ftp://ftp.openldap.org/incoming/ondrej-kuznik-20101202-unique_bypass_v2.tgz >> >> Is there anything else that comes to mind? > > I'm not sure it merits a config keyword. We already have instances where > administrators are implicitly allowed to bypass rules that restrict normal > users, and replication is obviously a system-level operation, not user level. > Rereading the discussions makes me agree with you. I have prepared a patch without the config keyword and modified the slapo-unique manpage accordingly. ftp://ftp.openldap.org/incoming/ondrej-kuznik-20110506-unique_bypass_v3.tgz Again the IPR notice: The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3D6ZkACgkQ9GWxeeH+cXtv7ACgl+6zPsyecGdWxjEnDL2CPDDp 2HoAoJ3D1XcuAJ1d+L/kwLLBltbo/ifo =RyJh -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

(ITS#6932) Strange assert()s
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard Klocwork reports a number of strange assert()s, typically assert(function parameter != NULL) after dereferencing it. Also some pointless ones, like if (ptr->foo) { bar = ptr; assert(bar != NULL); } I'll move these, along with some not found by Klocwork. At the same time, I'll change some nearby code to use alredy-computed values, e.g. be = op->o_bd; bi = op->o_bd->bd_info; can become bi = be->bd_info;

1 0

(ITS#6931) ldap_get_option(NULL, LDAP_OPT_SESSION_REFCNT, ) crash
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldap_get_option(,LDAP_OPT_SESSION_REFCNT,) does not catch ld=NULL. Klocwork issue#111. Fixing.

1 0

Re: (ITS#6918) #include statement unsafe
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

hyc(a)symas.com writes: >quanah(a)zimbra.com wrote: >> --On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: >> >>> hyc(a)symas.com writes: >>>> Nothing in the OpenLDAP code issues a truncate operation of any sort. >>> >>> There are several fopen(filename, "w") calls, which truncate the file. >>> Maybe the error confuses slapd so it takes a detour into one of them. > > Irrelevant. In Windows the OS prevents you from writing to an executable file > that is currently running. I.e., it is impossible for this to be the cause. Aha. OK. I don't know Windows, so I was reacting to what you said, not to what you didn't say:-) > Try it yourself: Can't without Windows. > (...) > If you still believe it's happening inside slapd the obvious thing to do to > track this is to run slapd under gdb and set a few breakpoints. E.g., one at > the end of the config parser, and one at slapd's call to exit(). At each > breakpoint, check the filesize of the slapd.exe. Something like that was what I had in mind, yes. I might try anyway. -- Hallvard

1 0

(ITS#6930) Socket leak in ldap_connect_to_path(too long path)
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: master, 2.4.24 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldap_connect_to_path() verifies its parameters after instead of before socket(), and does not close the socket on failure. Also the cleanup code can be simplified. Found by Klocwork, issue#117.

1 0

(ITS#6929) lutil_get_filed_password() filed descriptor leak
by h.b.furuseth＠usit.uio.no 05 May '11

05 May '11

Full_Name: Hallvard B Furuseth Version: HEAD, 2.4.24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard lutil_get_filed_password() does not always close the file on error. Found with Klocwork: Issue #203. Fixing.

1 0

Re: (ITS#6918) #include statement unsafe
by hyc＠symas.com 05 May '11

05 May '11

quanah(a)zimbra.com wrote: > --On Monday, May 02, 2011 12:53 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> hyc(a)symas.com writes: >>> Nothing in the OpenLDAP code issues a truncate operation of any sort. >> >> There are several fopen(filename, "w") calls, which truncate the file. >> Maybe the error confuses slapd so it takes a detour into one of them. Irrelevant. In Windows the OS prevents you from writing to an executable file that is currently running. I.e., it is impossible for this to be the cause. Try it yourself: #include <stdio.h> main(int argc, char *argv[]) { FILE *f=fopen(argv[0], "w"); if (f) printf("opened!\n"); else printf("failed!\n"); } >> Quanah, can you provide a full slapd.conf and command line which causes >> this? Not that I have a Windows box to test it on, but still... > > The command line was just slapd.exe -d -1 -f slapd.conf > > The slapd.conf itself is fairly small. The line that wrapped was the > include for inetOrgPerson. Everything obviously stopped when it hit the > wrapped include. > > ucdata-path "/opt/zimbra/openldap/ucdata" > include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" > include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" > include > "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" Yes, but since "everything obviously stopped" there's nothing in slapd that fopen's any files from that point. First of all this problem cannot be specific to the include statement, since the input validation will reject the line before ever going anywhere the code for include handling. So, you ought to be able to reproduce this issue using any config statement that requires a single argument. Second, slapd stops all parsing and simply exits when it hits a config error. And this is early enough in the config file that nothing else has been initialized yet, so the teardown processing has very little to do. If you still believe it's happening inside slapd the obvious thing to do to track this is to run slapd under gdb and set a few breakpoints. E.g., one at the end of the config parser, and one at slapd's call to exit(). At each breakpoint, check the filesize of the slapd.exe. -- -- 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#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 05 May '11

05 May '11

The root cause in this case is that the schema differs on the consumer and schema violation errors were logged at the consumer. Obviously this is a configuration error but the provider should not crash because of this!

1 0

(ITS#6928) slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed.
by michael＠stroeder.com 05 May '11

05 May '11

Full_Name: Michael Ströder Version: 2.4.25 OS: URL: Submission from: (NULL) (195.145.144.134) slapd (serving as provider) crashes from time to time (several times today!) when a consumer has some problems. I suspect this is related to ITS#6922 and therefore I suspect that Howard's answer is again just "there is no issue". The last lines in the logs always show that the consumer already sent an UNBIND and after that slapd dies with this failed assertion. conn=1090 op=1 INTERM oid=1.3.6.1.4.1.4203.1.9.1.4 conn=1090 op=2 UNBIND conn=1090 fd=112 closed connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! connection_read(112): no connection! slapd: daemon.c:942: slapd_clr_write: Assertion `((slap_daemon[id].sd_index[(s)]) != -1)' failed. /infraldap/sbin/start-slapd.sh: line 16: 28888 Aborted ${OPENLDAP_PREFIX}/libexec/slapd -h "ldap://0.0.0.0:389 ldaps://0.0.0.0:636 ldapi://%2ftmp%2finfraldap-socket????x-mod=0770" -d config,stats,stats2,sync -n slapd-e2-infra-ldap -u openldap -g openldap -f ${SLAPD_CONF}

1 0

Re: (ITS#6926) Delta-Sync produce undefined situation after split-brain
by Howard Chu 04 May '11

04 May '11

Delta-Syncrepl is only single-master. Closing this ITS.

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