openldap-bugs

openldap-bugs@openldap.org

1 participants
20954 discussions

Re: (ITS#6817) idassert-bind with SASL issues
by hyc＠symas.com 28 Feb '11

28 Feb '11

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2.40.14.92) > Submitted by: ando > > > When idassert-bind is configured to use SASL bind, an "authcID" needs to be > provided, while the "binddn" is not needed. However, if a "binddn" is not > provided as well, in some cases the proxiedAuthz control may be used > incorrectly. The need to configure the "binddn" is not documented, so this ITS > is minimally addressed by documenting this requirement. I tripped over this change while investigating #6711. Adding this requirement is certainly not the right solution; SASL Binds ordinarily don't require a BindDN and requiring it here just makes things confusing. Also with the fixes that I made for #6711 I don't believe the issue exists any more. Please describe the conditions where the problem occurs. > If the "binddn" is provided, everything works as expected, with the only minor > issue that the DN of the user as it is known to back-meta may not match the > actual identity the "authcID" assumed on the remote server. The "right" way to > address this problem consists in performing a "WhoAmI" (RFC 4532) right after > the bind, or better use a "authorization identity control" (RFC 3829) along with > the bind operation. Both approaches should be implemented, but they should not > be used unless explicitly requested. -- -- 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#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 28 Feb '11

28 Feb '11

Kartik Subbarao wrote: > I'd like to add one clarification to this message. I named the attached > test script that illustrates the two RESULT messages problem > test099-ppolicy-update, per Howard's previous advice not to duplicate > existing names. But I just realized that this script relies on the same > data files that I previously submitted (slapd-ppolicy.conf, > ppolicy.ldif) so when running this script please ensure that those files > are in place. Right, no problem. I've run your updated script against HEAD and see no errors, nor is there a duplicate result sent for the Bind operation. There's a config error because back-ldap in HEAD now always requires the binddn to be set in the idassert-bind directive. I have a feeling that this new requirement is bogus, and I just patched your script to set binddn="" to get around it for the moment. > Thanks, > > -Kartik > > On 02/02/2011 11:50 AM, Kartik Subbarao wrote: >>>> Another problem is that bind operations to the consumer server start to >> >> return two result messages -- one with the error code of the chained >> >> operation, and one with the error code of the bind operation. >> >> I'm continuing to see this problem, even after I fix the acl-bind and >> the 'manage' ACL configuration. See the attached for an updated test >> script that illustrates the problem -- I've added a bind with an >> incorrect password which should return 49, but instead is returning 0 to >> the client. >> >> The last line of output from the test script is: >> >> ldap bind operation returned 0, expected 49 >> >> For the relevant operation in slapd.2.log, I see the following: >> >> conn=1003 op=0 RESULT tag=103 err=0 text= >> [...] >> conn=1003 op=0 RESULT tag=97 err=49 text= >> >> slapd is returning two RESULT messages for the BIND operation. Error 0 >> seems to be from the successful chained modification of the >> pwdFailureTime attribute, and Error 49 seems to be for the incorrect >> password. >> >> -Kartik > > -- -- 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#6847) slapd segmentation fault
by Howard Chu 28 Feb '11

28 Feb '11

The information you provided is useless. Please read http://www.openldap.org/faq/data/cache/59.html

1 0

Re: (ITS#6845) sortvals oddities - with more information
by hyc＠symas.com 28 Feb '11

28 Feb '11

aweits(a)rit.edu wrote: > Full_Name: Andrew Elble > Version: 2.4.24 / CVS Head > OS: Solaris / MacOS > URL: > Submission from: (NULL) (129.21.6.207) > Thanks for the detailed report. > > We are using sortvals on both member and memberUid. We have been > seeing duplicate member/memberUid attributes on some objects that have > been modified (as well as a lack of sorting on those attributes). It > seemed that there was a correlation between modifies to objects that > experienced deadlocks and the objects that had duplicate > member/memberUid attributes on them. We put the seqmod overlay in > place - and this reduced the number of occurrences of the issue but > did not eliminate them. > > Upon further investigation, I discovered that it was possible to > bypass the sorting behavior if the object was not created with an > instance of the attribute with sorting enabled as a part of it. > > It would seem that attr_merge() (in attr.c) should have something like this: > > if ( *a == NULL ) { > *a = attr_alloc( desc ); > if (desc->ad_type->sat_flags& SLAP_AT_SORTED_VAL) { > (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; > } > } else { This is now fixed in HEAD in value.c. > Further pursuing the issue, I started to focus on the index deletion > code that was changed as a part of ITS#5183. Specifically, the > portion of code within bdb_modify_internal() (in back-bdb/modify.c) > that is commented: > > /* Move deleted values to end of array */ > > This code modifies save_attrs, which is actually apparently a pointer > to memory that resides within the cache. If a deadlock occurs, these > changes are not reverted, thereby corrupting the entry in the cache. I > replaced this code with the pre-ITS#5183 code and I am no longer able > to 'break' the object and insert duplicate member/memberUids. This is now fixed in HEAD. > I also found it surprising that the call to bdb_idl_cache_del() in > bdb_idl_delete_key() in back-bdb/idl.c occurred prior to any calls to > the database? I see what you mean. I don't think this causes any harm though. > I can answer any questions about the specifics of the environment > in which where we are seeing this - it is a somewhat difficult problem to > reproduce outside of our production environment. I'm not terribly > familiar with the code - I'm looking to see if I have collected enough > data here to open an ITS to have this fixed. (or if I'm just way off base) > > > Thanks, > > Andy > > -- -- 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#6847) slapd segmentation fault
by dkastens＠uos.de 28 Feb '11

28 Feb '11

Full_Name: Dirk Kastens Version: 2.4.24 OS: Red Hat Enterprise Linux Server release 5.6 (kernel 2.6.18-238.1.1.el5xen) URL: Submission from: (NULL) (2001:638:508:3d0:74e8:28f7:184a:4cdf) I updated our openldap master and two replica servers to 2.4.24 (self-compiled) last week. Saturday morning, both replicas crashed at the same time with a segementation fault: kernel: slapd[2150]: segfault at 0000000000000059 rip 00000000004fb9e7 rsp 0000000042f9e630 error 4 kernel: slapd[9451]: segfault at 0000000000000059 rip 00000000004fb9e7 rsp 000000004563f630 error 4 Running slapd with valgrind --tool=memcheck --leak-check=full gives: ==31485== LEAK SUMMARY: ==31485== definitely lost: 0 bytes in 0 blocks ==31485== indirectly lost: 0 bytes in 0 blocks ==31485== possibly lost: 110,162 bytes in 4,698 blocks ==31485== still reachable: 6,942,591 bytes in 26,974 blocks ==31485== suppressed: 0 bytes in 0 blocks ==31485== Reachable blocks (those to which a pointer was found) are not shown. ==31485== To see them, rerun with: --leak-check=full --show-reachable=yes ==31485== ==31485== For counts of detected and suppressed errors, rerun with: -v ==31485== ERROR SUMMARY: 256 errors from 256 contexts (suppressed: 16 from 7) ==31485== Warning: set address range perms: large range [0xba78000, 0x1fa7a000) (defined) ==31485== Warning: set address range perms: large range [0xba78000, 0x1fa7a000) (noaccess) ==31485== Warning: invalid file descriptor -1 in syscall read()

1 0

(ITS#6846) Deadlock in back-meta
by jorge.perez.burgos＠ericsson.com 28 Feb '11

28 Feb '11

Full_Name: Jorge Perez Burgos Version: 2.4.15 OS: SLES 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.235.15.243) There is a deadlock in back-meta code, the problem is that this thread get the lock two times, the first is the one that show the trace, but previous in the method meta_back_retry it has already the lock. (gdb) bt #0 0x00002b6e1a0706a8 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0 #1 0x00002b6e1a06c9fb in _L_mutex_lock_92 () from /lib64/libpthread.so.0 #2 0x00002b6e1a06c455 in pthread_mutex_lock () from /lib64/libpthread.so.0 #3 0x00000000004eb715 in meta_back_bind_op_result (op=0x2aab35d80020, rs=0x6eb6ad20, mc=0x2aab35e58be0, candidate=4, msgid=1, sendok=<value optimized out>) at bind.c:388 #4 0x00000000004eba9f in meta_back_proxy_authz_bind (mc=0x2aab35e58be0, candidate=4, op=0x2aab35d80020, rs=0x6eb6ad20, sendok=LDAP_BACK_SENDERR) at bind.c:1534 #5 0x00000000004ebc21 in meta_back_single_dobind (op=0x2aab35d80020, rs=0x6eb6ad20, mcp=0x6eb6a750, candidate=4, sendok=LDAP_BACK_SENDERR, nretries=276864893, dolock=0) at bind.c:600 #6 0x00000000004f3c4f in meta_back_retry (op=0x2aab35d80020, rs=0x6eb6ad20, mcp=0x6eb6a750, candidate=4, sendok=LDAP_BACK_SENDERR) at conn.c:721 #7 0x00000000004e9ffc in meta_back_add (op=0x2aab35d80020, rs=0x6eb6ad20) at add.c:184 #8 0x000000000044c196 in fe_op_add (op=0x2aab35d80020, rs=0x6eb6ad20) at add.c:334 #9 0x00000000004a4832 in overlay_op_walk (op=0x2aab35d80020, rs=0x6eb6ad20, which=op_add, oi=0x905850, on=0x0) at backover.c:669 #10 0x00000000004a4db5 in over_op_func (op=0x2aab35d80020, rs=0x6eb6ad20, which=op_add) at backover.c:721 #11 0x000000000044ca02 in do_add (op=0x2aab35d80020, rs=0x6eb6ad20) at add.c:194 #12 0x0000000000445bab in connection_operation (ctx=0x6eb6ae70, arg_v=<value optimized out>) at connection.c:1115 #13 0x0000000000446087 in connection_read_thread (ctx=0x6eb6ae70, argv=<value optimized out>) at connection.c:1241 #14 0x000000000052398a in ldap_int_thread_pool_wrapper (xpool=0x788e70) at tpool.c:663 #15 0x00002b6e1a06a193 in start_thread () from /lib64/libpthread.so.0 #16 0x00002b6e19814dfd in clone () from /lib64/libc.so.6

1 0

(ITS#6845) sortvals oddities - with more information
by aweits＠rit.edu 25 Feb '11

25 Feb '11

Full_Name: Andrew Elble Version: 2.4.24 / CVS Head OS: Solaris / MacOS URL: Submission from: (NULL) (129.21.6.207) We are using sortvals on both member and memberUid. We have been seeing duplicate member/memberUid attributes on some objects that have been modified (as well as a lack of sorting on those attributes). It seemed that there was a correlation between modifies to objects that experienced deadlocks and the objects that had duplicate member/memberUid attributes on them. We put the seqmod overlay in place - and this reduced the number of occurrences of the issue but did not eliminate them. Upon further investigation, I discovered that it was possible to bypass the sorting behavior if the object was not created with an instance of the attribute with sorting enabled as a part of it. It would seem that attr_merge() (in attr.c) should have something like this: if ( *a == NULL ) { *a = attr_alloc( desc ); if (desc->ad_type->sat_flags & SLAP_AT_SORTED_VAL) { (*a)->a_flags |= SLAP_ATTR_SORTED_VALS; } } else { Further pursuing the issue, I started to focus on the index deletion code that was changed as a part of ITS#5183. Specifically, the portion of code within bdb_modify_internal() (in back-bdb/modify.c) that is commented: /* Move deleted values to end of array */ This code modifies save_attrs, which is actually apparently a pointer to memory that resides within the cache. If a deadlock occurs, these changes are not reverted, thereby corrupting the entry in the cache. I replaced this code with the pre-ITS#5183 code and I am no longer able to 'break' the object and insert duplicate member/memberUids. I also found it surprising that the call to bdb_idl_cache_del() in bdb_idl_delete_key() in back-bdb/idl.c occurred prior to any calls to the database? I can answer any questions about the specifics of the environment in which where we are seeing this - it is a somewhat difficult problem to reproduce outside of our production environment. I'm not terribly familiar with the code - I'm looking to see if I have collected enough data here to open an ITS to have this fixed. (or if I'm just way off base) Thanks, Andy

1 0

(ITS#6844) AIX 6.1 | 7.1 not supported in "configure"
by joshua.taylor＠ubs.com 25 Feb '11

25 Feb '11

Full_Name: Joshua Taylor Version: 2.4.24 OS: AIX 6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.134.254.26) the configure script has no support for aix6* or aix7*, resulting in assuming no shared libraries are supported. Simply going in after each reference to "aix5*" and adding, " | aix6* | aix7* " enables shared library support. Also, support for IA64 on aix is no more. I'm not even sure there was ever a version that *actually* ran on IA64 cpus.

1 0

Re: (ITS#6841) slapd segfault error 7
by quanah＠zimbra.com 24 Feb '11

24 Feb '11

--On Tuesday, February 22, 2011 10:54 AM +0000 tecnica(a)florasul.pt wrote: > This is the output from strace -o slapd strace is useless. Please have a core file generated, with debugging symbols, and send the full backtrace. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2.4.23 / Debian 6.0 i386: segfault at 811db38 ip 080c1e80 sp b2cf4b80 error 7 in slapd
by David Touzeau 24 Feb '11

24 Feb '11

Dear We have an problem using $OpenLDAP: slapd 2.4.23 (Nov 22 2010 23:39:34) $#012#011@biber:/build/buildd-openldap_2.4.23-7-i386-mi96UQ/openldap-2.4.23/debian/build/servers/slapd The same issue has been be replicated on 2.4.24 When we analyze the debug logs, the crash is performed each time we see this line : is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass attribute How can we prevent this crash or fix it ? here it is a piece of logs that detect the crash. Feb 22 14:50:21 pm02 slapd[12126]: >>> dnPrettyNormal: <cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com> Feb 22 14:50:21 pm02 slapd[12126]: <<< dnPrettyNormal: <cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com>, <cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com> Feb 22 14:50:21 pm02 slapd[12126]: bdb_dn2entry("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: => hdb_dn2id("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) Feb 22 14:50:21 pm02 slapd[12126]: oc_check_required entry (cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com), objectClass "ArticaHostName" Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type "objectClass" Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type "cn" Feb 22 14:50:21 pm02 slapd[12126]: oc_check_allowed type "structuralObjectClass" Feb 22 14:50:21 pm02 slapd[12126]: bdb_dn2entry("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: => hdb_dn2id("cn=webmail.e.florasul.pt,cn=artica,dc=my-domain,dc=com") Feb 22 14:50:21 pm02 slapd[12126]: <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) Feb 22 14:50:21 pm02 slapd[12126]: is_entry_objectclass("", "2.16.840.1.113730.3.2.6") no objectClass attribute Feb 22 14:50:21 pm02 kernel: [13697.801217] slapd[13777]: segfault at 811db38 ip 080c1e80 sp b2cf4b80 error 7 in slapd[8048000+11b000] best regards

2 1

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