openldap-bugs

openldap-bugs@openldap.org

21001 discussions

(ITS#5551) assertion causes application failure
by aej＠wpi.edu 12 Jun '08

12 Jun '08

Full_Name: Allan E. Johannesen Version: 2.4.10 OS: Linux EL 4 URL: Submission from: (NULL) (130.215.24.208) Recently, incorrect "User unknown" have been appearing in the mail logs with some frequency, accompanied by nss ldap error messages. I can't see into that application, so I'm not sure what's going on. At another place, I've had an application failing where it sees an assertion fail, so this may be the cause of the other problem. Did some debug code remain in the 2.4.10 release? [New Thread 1367456096 (LWP 14151)] [New Thread 1388435808 (LWP 14165)] [Thread 1514314080 (LWP 14129) exited] [New Thread 1514314080 (LWP 14178)] [Thread 1252067680 (LWP 13877) exited] [Thread 1241577824 wpi closed] [Thread 1241577824 (LWP 13824) exited] [New Thread 1241577824 (LWP 14188)] [Thread 1199618400 (LWP 13994) exited] [Thread 1231087968 wpi closed] [Thread 1231087968 (LWP 13888) exited] [New Thread 1231087968 (LWP 14199)] [Thread 1115699552 wpi closed] [Thread 1115699552 (LWP 13946) exited] [Thread 1126189408 alum_connect ldap://alum.wpi.edu] [New Thread 1115699552 (LWP 14212)] [Thread 1136679264 wpi_connect ldap://ldapv2back.wpi.edu] [New Thread 1199618400 (LWP 14223)] [Thread 1105209696 (LWP 14011) exited] [New Thread 1105209696 (LWP 14234)] [Thread 1294027104 (LWP 13865) exited] [Thread 1335986528 (LWP 13839) exited] [Thread 1094719840 (LWP 14057) exited] [New Thread 1094719840 (LWP 14251)] [Thread 1346476384 alum_connect ldap://alum.wpi.edu] [New Thread 1335986528 (LWP 14271)] [New Thread 1294027104 (LWP 14285)] [Thread 1126189408 alum closed] [New Thread 1252067680 (LWP 14286)] [Thread 1126189408 (LWP 14022) exited] [New Thread 1398925664 (LWP 14297)] [New Thread 1126189408 (LWP 14308)] [Thread 1294027104 (LWP 14285) exited] [New Thread 1409415520 (LWP 14318)] [Thread 1157658976 wpi closed] [Thread 1157658976 (LWP 13960) exited] [New Thread 1157658976 (LWP 14329)] [New Thread 1294027104 (LWP 14342)] [Thread 1377945952 (LWP 13928) exited] [New Thread 1377945952 (LWP 14353)] [New Thread 1419905376 (LWP 14363)] [Thread 1325496672 (LWP 14100) exited] [Thread 1294027104 (LWP 14342) exited] [Thread 1136679264 wpi closed] [Thread 1136679264 (LWP 14033) exited] [New Thread 1136679264 (LWP 14380)] [Thread 1262557536 (LWP 13971) exited] [Thread 1220598112 (LWP 14111) exited] [Thread 1283537248 (LWP 14140) exited] [Thread 1346476384 alum closed] [Thread 1346476384 (LWP 14069) exited] [Thread 1367456096 wpi_connect ldap://ldapv2back.wpi.edu] phish+: decode.c:779: ber_scanf: Assertion `((ber)->ber_opts.lbo_valid==0x2)' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 1367456096 (LWP 14151)] 0x000000382342e25d in raise () from /lib64/tls/libc.so.6 (gdb) quit The program is running. Exit anyway? (y or n) y Is there debug output you would like from me?

1 0

(ITS#5550) Unable to do scp from and to server ldap
by karim.bourenane＠orange-ftgroup.com 12 Jun '08

12 Jun '08

Full_Name: Bourenane Version: Openldap-server-2.3.41 / and clien OS: FreeBSD 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (57.250.229.136) Hi All My server running fine, with ldap and ldaps. Is i do a command SCP from any server to user i have : server# scp kbourena@ldap-rain:/home/kbourena/toto.txt . Password: unknown user 1206 server# On ldap-rain

1 0

(ITS#5549) slapd SEGV faults in entry_partsize when monitoring
by andreas.mueller＠othello.ch 11 Jun '08

11 Jun '08

Full_Name: Andreas Mueller Version: 2.4.9 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.134.170.35) We have four slapd servers in a mirrormode configuration. This generally works well. We monitor these servers using ldapsearches to cn=Monitor every minute, and collect performance data to construct load/performance graphs with rrdtool. Unfortunately, it sometimes happens that slapd crashes during the monitoring query. Using gdb, we were able to get a stack backtrace: Core was generated by `/usr/local/libexec/slapd'. Program terminated with signal 11, Segmentation fault. #0 0x0005fd48 in entry_partsize () (gdb) bt #0 0x0005fd48 in entry_partsize () #1 0x000603b4 in entry_flatsize () #2 0x0006a5c8 in slap_send_search_entry () #3 0x00134330 in monitor_send_children () #4 0x001348e0 in monitor_back_search () #5 0x000523ac in fe_op_search () #6 0x00051b64 in do_search () #7 0x0004dd8c in connection_operation () #8 0x0004e4c4 in connection_read_thread () #9 0x001a22a8 in ldap_int_thread_pool_wrapper () #10 0xfe3c5800 in __tbl_10_huge_digits () from /lib/libc.so.1 All cores obtained so far show that the segmentation fault occured at the same location inside entry_partsize. Unfortunately we cannot systematically reproduce this behaviour, and we also cannot get the line number (binaries are stripped). We have not tried other versions or other platforms. For production, we use the versions available in package form from www.sunfreeware.com, but the error also happens on servers we have compiled ourselves from the sources.

1 0

(ITS#5548) syncprov evaluates ACL rules with wrong connection info
by rein＠OpenLDAP.org 11 Jun '08

11 Jun '08

Full_Name: Rein Tollevik Version: 2.4.10 (CVS head) OS: linux, solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.215.2.34) Submitted by: rein Access control rules that uses connection data are evaluated using the wrong connection structure. The problem is in syncprov_matchop() where it around line 1233 assigns: op2.o_hdr = op->o_hdr; This causes ACL rules to be tested against the connection that made the change, not the syncrepl connection. It should retain the value from ss->s_op. Rein Tollevik Basefarm AS

1 0

(ITS#5547) JLDAP: unauthenticated bind silently converted to anonymous bind
by johannes.geiger＠vkb.de 11 Jun '08

11 Jun '08

Full_Name: Johannes Geiger Version: n/a OS: Windows, Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.245.172.60) While the documentation of JLDAP states that only authenticated and anonymous bind are supported, JLDAP silently converts an unauthenticated bind to an anonymous one. >From LDAPconnection.java boolean anonymous = false; if( passwd.length == 0) { anonymous = true; // anonymous, passwd length zero with simple bind dn = ""; // set to null if anonymous } (I even think there is a bug in this, as the flag "anonymous" stays on false, if there is a password given but no dn.) This is in fact a security issue, as - while unauthenticated bind usually is forbidden by the server, anonymous bind is allowed - the client using bind for authentication reasons might be led to believe in successful authentication whereas the server only accepted an anonymous bind and did not do any credential verification.

1 0

(ITS#5546) slapd aborts using slapo-pcache when caching negative searches
by toby＠inf.ed.ac.uk 11 Jun '08

11 Jun '08

Full_Name: Toby Blake Version: 2.4.10 OS: Scientific Linux 5.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.215.218.33) Hi there, If I specify a negative ttl when using slapo-pcache, e.g... overlay pcache proxycache bdb 5000 1 500 300 proxycachequeries 10000 proxyattrset 0 uid # proxytemplate using ttl and negative ttl of 1800 proxytemplate (uid=) 0 1800 1800 ... slapd aborts whenever there is a negative search to cache. The cause of this seems to be the assert(0) in pcache.c:pcache_op_cleanup, code fragment starting line 2010... switch ( si->caching_reason ) { case PC_POSITIVE: cache_entries( op, rs, &qc->q_uuid ); break; case PC_SIZELIMIT: qc->q_sizelimit = rs->sr_nentries; break; default: assert( 0 ); break; } The value of si>caching_reason when slapd SIGABRTs is PC_NEGATIVE (which isn't handled by the switch statement). Let me know if you need any more info... Cheers Toby Blake School of Informatics University of Edinburgh

1 0

(ITS#5545) Inconsistency in multi-master setup
by st＠itsc.cuhk.edu.hk 11 Jun '08

11 Jun '08

Full_Name: SiuTo Wong Version: 2.4.10 OS: CentOS 5 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.189.29.184) Have setup 2-node multi-master configuration. Found that when operating on same set of users at high loading, there will be consistency between the masters. The problem can be simulated by running copies of perl script to add/delete the same set of users simultaneously, e.g. add user a001 - a100 & delete user a001 - a100 & or add user a001 - a100 & add user a001 - a100 & There is no problem if multiple threads of add/delete are running, when operating on different sets of users. Attached please find snap of syncrepl setting of one of the servers. All attributes are the same on both masters, except serverId, rid, and provider. Thanks a lot. ====================== cut here ====================== index entryCSN,entryUUID eq lastmod on serverId 2 syncrepl rid=002 provider=ldap://192.168.28.70 starttls=yes tls_reqcert=never tls_cacert=/etc/CA/cacert.pem type=refreshAndPersist retry="5 + 5 +" searchbase="dc=mydomain,dc=hk" schemachecking=off bindmethod=simple binddn="cn=srAdmin,ou=People,dc=mydomain,dc=hk" credentials=youguess interval=00:00:00:05 mirrormode true overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 limits dn.exact="cn=srAdmin,ou=People,dc=cuhk,dc=edu,dc=hk" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited ====================== cut here ======================

1 0

Re: (ITS#5462) Allow setting of RANDOM_FILE for gnutls
by hyc＠symas.com 10 Jun '08

10 Jun '08

pogma(a)thewrittenword.com wrote: > Full_Name: Peter O'Gorman > Version: 2.4.8 > OS: multiple > URL: ftp://ftp.openldap.org/incoming/the-written-word-080410.patch > Submission from: (NULL) (24.76.165.223) > > > gcrypt-1.4.x and later allow the egd socket path to be set. This patch allows > the conf file option to work when building openldap with gnutls on systems that > do not have a /dev/random. Hm, this patch is a silent no-op if the gcrypt function is missing. Currently the randfile option is already documented as being ignored by GNUtls. I would prefer that the behavior is absolutely consistent - either the feature always works or is always ignored. Perhaps we should require gcrypt 1.4 or newer? -- -- 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#5464) ucred guarded by __USE_GNU in glibc 2.8
by hyc＠symas.com 06 Jun '08

06 Jun '08

rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: Any > OS: Linux (glibc 2.8) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.8.71.17) > > > Newer glibc Version guards the definition of struct ucred (e.g. used in > liblutil/getpeereid.c) by __USE_GNU, hence it is only available when _GNU_SOURCE > is defined. > > The matching glibc changelog only say "Cleanup namespace.". Here's the diff: > > http://sourceware.org/cgi-bin/cvsweb.cgi/libc/sysdeps/unix/sysv/linux/bits/… This is a bug in glibc. Luca Scamoni reported it upstream here http://sources.redhat.com/bugzilla/show_bug.cgi?id=6545 -- -- 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#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org 05 Jun '08

05 Jun '08

On Jun 5, 2008, at 6:31 AM, h.b.furuseth(a)usit.uio.no wrote: > And when they add the absent A and that fails, but we can fix that. I think the best is option is disallow addition of an unlisted subject and disallow the removal of a unlisted subclass (except by replace). This will provide more a more consistent and symmetric behavior. In your initial report, it was this inconsistent and non-symmetric behavior that was your most significant concern. As far as RFC conformance goes, I argue that with this change, the behavior would be fully conformant. No where in the RFCs does it require servers to return implicitly added values, no where in the RFCs does it preclude servers from removing implicitly added values upon removal of values which caused there addition. The concern I have is impact on clients which add a class and then delete that class, expecting it just to work. But if that class is subclass, and the add causes the insertion of some other class, then the delete will either leave that other class there or lead to an error, both undesirable and unexpected behaviors. I think the mistake that LDAP designers made (long ago) was not to require LDAP CLIENTS to provide all (non-top) classes, as is required of DAP clients. Regarding objectClass being special (especially with regard to its equality matching rule): consider (objectClass=top) and X.500 "top may be omitted" statement. -- Kurt

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