(ITS#6858) segfault on schema modification in cn=config
by zerbe＠phil.uni-duesseldorf.de
Full_Name: Sebastian Zerbe
Version: 2.4.23-7
OS: Debian GNU/Linux 6.0
URL: ftp://ftp.openldap.org/incoming/sebastian-zerbe-110309.tar.gz
Submission from: (NULL) (134.99.58.27)
Trying to modify the local schema cn={5}philfak,cn=schema,cn=config with the
given ldif-file modify_phil_schema.ldif using "ldapmodify -x -D
cn=admin,cn=config -W -f modify_phil_schema.ldif" results in a slapd crash with
kernel log entries like these:
[3451954.217075] slapd[2593]: segfault at 70 ip 080bd73f sp ae5f9910 error 4 in
slapd[8048000+11b000]
[3451972.088717] slapd[5716]: segfault at 70 ip 080bd73f sp b1bfe910 error 4 in
slapd[8048000+11b000]
[3452718.916547] slapd[5830]: segfault at 70 ip 080bd73f sp b1992910 error 4 in
slapd[8048000+11b000]
Further debugging is nearly impossible. If slapd is running in gdb it does not
crash (but the modifications do not take place either)...
10 years, 10 months
Re: (ITS#6853) slapadd/slapindex -q hang
by quanah＠zimbra.com
--On March 4, 2011 11:14:46 PM +0000 dhawes(a)vt.edu wrote:
> Tested, and working. Thanks for the fix.
We're still seeing this happen sporadically with slapindex -q <attribute>
i.e., reindexing a single attribute instead of the entire DB
Thread 2 (Thread 0x96591ba0 (LWP 10652)):
#0 0xffffe410 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7dd21e6 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
No symbol table info available.
#2 0xb7f4b5d8 in ldap_pvt_thread_cond_wait (cond=0xb776bf80,
mutex=0xb776bf50) at thr_posix.c:277
No locals.
#3 0xb77376f4 in bdb_tool_trickle_task (ctx=0x965912bc, ptr=0x82eb728) at
tools.c:1242
env = 0x82eb728
wrote = -1208699249
#4 0xb7f4a33c in ldap_int_thread_pool_wrapper (xpool=0x81bda78) at
tpool.c:685
pool = 0x81bda78
task = 0x82ee038
work_list = 0x81bdaf8
ctx = {ltu_id = 2522422176, ltu_key = {{ltk_key = 0x0, ltk_data =
0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key
= 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0,
ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data =
0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key
= 0x0, ltk_data = 0xb7f9b049, ltk_free = 0xb7dcc732}, {
ltk_key = 0x0, ltk_data = 0xb7fa7ff4, ltk_free = 0xb7bffd80},
{ltk_key = 0x0, ltk_data = 0x96591388, ltk_free = 0xb7f963d0
<do_lookup_x+640>}, {ltk_key = 0x0, ltk_data = 0xb7dcc75a, ltk_free = 0}, {
ltk_key = 0x0, ltk_data = 0xb7dcb324, ltk_free = 0x69cb120},
{ltk_key = 0x0, ltk_data = 0xd696910, ltk_free = 0xe}, {ltk_key = 0x0,
ltk_data = 0xb7a874a0, ltk_free = 0xb7a8ffe0}, {ltk_key = 0x0,
ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data =
0x2, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0xb7fa7ff4},
{ltk_key = 0x0, ltk_data = 0x96591414, ltk_free = 0x96591428}, {
ltk_key = 0x0, ltk_data = 0x96591414, ltk_free = 0xb7fa8830},
{ltk_key = 0x0, ltk_data = 0xb7bf7dd8, ltk_free = 0x1}, {ltk_key = 0x0,
ltk_data = 0x1, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0},
{ltk_key = 0x0, ltk_data = 0xb7f272a0, ltk_free = 0xb7dcb69d}, {ltk_key =
0x0, ltk_data = 0x1000000, ltk_free = 0}, {ltk_key = 0x0,
ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data =
0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key
= 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0,
ltk_data = 0xb7a8f000, ltk_free = 0xb7bf7508}, {ltk_key =
0x0, ltk_data = 0xb7dcb324, ltk_free = 0xb7f272a0}, {ltk_key = 0x0,
ltk_data = 0xb7f9a24d, ltk_free = 0xb7f27448}, {ltk_key = 0x0,
ltk_data = 0x1, ltk_free = 0x1}}}
kctx = 0x0
i = 32
keyslot = 522
hash = 5777930
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#5 0xb7dce35b in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#6 0xb7b43c0e in clone () from /lib/libc.so.6
No symbol table info available.
Thread 1 (Thread 0xb7a826b0 (LWP 10610)):
#0 0xffffe410 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7dd21e6 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
No symbol table info available.
#2 0xb7f4b5d8 in ldap_pvt_thread_cond_wait (cond=0x81bda94,
mutex=0x81bda7c) at thr_posix.c:277
No locals.
#3 0xb7f49fe7 in ldap_pvt_thread_pool_destroy (tpool=0xbf995780,
run_pending=0) at tpool.c:582
pool = 0x81bda78
pptr = 0x81bda78
task = 0x0
#4 0xb7f49332 in ldap_int_thread_pool_shutdown () at tpool.c:181
pool = 0x81bda78
#5 0xb7f48aa0 in ldap_pvt_thread_destroy () at threads.c:70
No locals.
#6 0x080af918 in slap_destroy () at init.c:273
rc = 0
#7 0x080ff5f2 in slap_tool_destroy () at slapcommon.c:865
rc = 0
#8 0x080ffb9b in slapindex (argc=1, argv=0xbf9959bc) at slapindex.c:107
id = 4294967295
rc = 0
progname = 0x813ae0a "slapindex"
ad = 0x8239440
adv = 0xbf9959bc
__PRETTY_FUNCTION__ = "slapindex"
#9 0x08057783 in main (argc=7, argv=0xbf9959a4) at main.c:403
i = 3
no_detach = 0
rc = 1
urls = 0x0
username = 0x0
groupname = 0x0
sandbox = 0x0
syslogUser = 160
g_argc = 7
g_argv = 0xbf9959a4
configfile = 0x0
configdir = 0x0
serverName = 0xbf997206 "slapindex"
serverMode = 1
scp = 0x0
scp_entry = 0x0
debug_unknowns = 0x0
syslog_unknowns = 0x0
serverNamePrefix = 0x811c33f ""
l = 134548137
slapd_pid_file_unlink = 0
slapd_args_file_unlink = 0
firstopt = 1
__PRETTY_FUNCTION__ = "main"
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
10 years, 10 months
Re: (ITS#6461) back-sql quote characters in query
by atze_80＠web.de
Can confirm this with openldap 2.4.24.
Using ldap search filters like this:
(cn=blabla' or '1'='1)
is at least causing my postgres to eat all CPU cycles it can get (LDAP
data is based on complex view). I do not have write access enabled for
that particular openLDAP installation, but I also assume that SQL
Injection is possible. Beside being an obviuos malfunction, this should
be considered a security issue.
atze
10 years, 10 months
Re: (ITS#6856) OpenLDAP 2.4.23 / db 4.7.25 lockup 100% CPU
by hyc＠symas.com
requate(a)univention.de wrote:
> Full_Name: Arvid Requate
> Version: 2.4.23
> OS: Debian Lenny
> URL: http://apt.univention.de/download/temp/openldap/trace_openldap_2.4.23_db_...
> Submission from: (NULL) (82.198.197.8)
>
>
> With OpenLDAP 2.4.23 and bdb 4.7.25 we seem to hit something like a race
> condition that can be triggered by concurrent ldapdelete and search_s
> operations.
> Though a bit simmilar, this condition does no quite match the details of
> ITS#5707. The URL provides a tar archive containing three gdb traces and
> corresponding slapd log output (loglevel: trace args stats) of three cases of
> lockup, where slapd hangs consuming 100% of CPU after a couple of modifications
> with the shell script contained in the tar archive and remains unresponsive
> until restartet.The number of successful operations varies between the test
> runs.
>
> Berkeley DB 4.7.25 (May 15, 2008) was built with Oracle patches for Bugs #16415
> and #16541 and configure options "--enable-posixmutexes
> --with-mutex=POSIX/pthreads".
>
> The test machine is a single processor/single core 686 VM running Linux 2.6.32
> 686 bigmem. The concurrent searches are performed by a separate process that
> gets informed about ldap modifications (via file) by an slapd overlay module
> called 'translog'. To me the traces do not seem to indicate a problem in the
> overlay code (i.e. there is no reference to the on_response function
> "translog_response" in the traces).
>
> Maybe there is some obvious point here we are missing? More debug details can be
> provided if necessary.
Try again using 2.4.24. There was a bug with back-bdb delete fixed recently
(ITS#6577) so the relevant code has changed since .23.
Also try a newer BerkeleyDB. We've had other deadlocks with 4.7 that no longer
occur in 4.8.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 10 months
(ITS#6857) chain overlay change FLAGS of underlying database
by rhafer＠suse.de
Full_Name: Ralf Haferkamp
Version: RE24, HEAD
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (92.252.38.247)
The chain-overlay adds SLAP_DBFLAG_NOLASTMOD to the flags of the database for
which chaining is to be configured. Example:
--------------------
database hdb
suffix o=test
rootdn o=test
rootpw secret
directory /tmp/ldap
overlay chain
chain-return-error TRUE
chain-uri ldap://ldap.server
-------------------
With the above configuration slapd will no longer maintain the
"modifyTimeStamp", "modifiersName", etc. Attributes for write operations to the
"o=test" database anymore.
Note: This bug is only present when using a slapd.conf base configuration.
Fix is almost ready.
10 years, 10 months
(ITS#6856) OpenLDAP 2.4.23 / db 4.7.25 lockup 100% CPU
by requate＠univention.de
Full_Name: Arvid Requate
Version: 2.4.23
OS: Debian Lenny
URL: http://apt.univention.de/download/temp/openldap/trace_openldap_2.4.23_db_...
Submission from: (NULL) (82.198.197.8)
With OpenLDAP 2.4.23 and bdb 4.7.25 we seem to hit something like a race
condition that can be triggered by concurrent ldapdelete and search_s
operations.
Though a bit simmilar, this condition does no quite match the details of
ITS#5707. The URL provides a tar archive containing three gdb traces and
corresponding slapd log output (loglevel: trace args stats) of three cases of
lockup, where slapd hangs consuming 100% of CPU after a couple of modifications
with the shell script contained in the tar archive and remains unresponsive
until restartet.The number of successful operations varies between the test
runs.
Berkeley DB 4.7.25 (May 15, 2008) was built with Oracle patches for Bugs #16415
and #16541 and configure options "--enable-posixmutexes
--with-mutex=POSIX/pthreads".
The test machine is a single processor/single core 686 VM running Linux 2.6.32
686 bigmem. The concurrent searches are performed by a separate process that
gets informed about ldap modifications (via file) by an slapd overlay module
called 'translog'. To me the traces do not seem to indicate a problem in the
overlay code (i.e. there is no reference to the on_response function
"translog_response" in the traces).
Maybe there is some obvious point here we are missing? More debug details can be
provided if necessary.
10 years, 10 months
Re: (ITS#6491) LDAP Error code 80 - Dn index delete failed
by apm＠one.com
I see this symptom too with both these versions:
OpenLDAP 2.4.21, BDB 4.8.26
OpenLDAP 2.4.23, BDB 4.8.30
ldapdelete -r failes with:
ldap_delete: Other (e.g., implementation specific) error (80)
additional info: DN index delete failed
I've copied the database files to a similar machine for debugging.
Here's the output for slapd -d1 when doing so:
=============================================================
do_bind: SASL/EXTERNAL bind: dn="cn=config" sasl_ssf=0
send_ldap_response: msgid=1 tag=97 err=0
ber_flush2: 14 bytes to sd 11
<== slap_sasl_bind: rc=0
connection_get(11): got connid=1001
connection_read(11): checking for input on id=1001
ber_get_next
ber_get_next: tag 0x30 len 86 contents:
op tag 0x63, time 1299502775
ber_get_next
conn=1001 op=1 do_search
ber_scanf fmt ({miiiib) ber:
>>> dnPrettyNormal: <o=xxx,dc=example,dc=com>
<<< dnPrettyNormal: <o=xxx,dc=example,dc=com>, <o=xxx,dc=example,dc=com>
ber_scanf fmt (m) ber:
ber_scanf fmt ({M}}) ber:
=> bdb_search
bdb_dn2entry("o=xxx,dc=example,dc=com")
search_candidates: base="o=xxx,dc=example,dc=com" (0x0025d3ca) scope=1
=> bdb_dn2idl("o=xxx,dc=example,dc=com")
<= bdb_dn2idl: get failed: DB_NOTFOUND: No matching key/data pair found
(-30988)
bdb_search_candidates: failed (rc=-30988)
bdb_search: no candidates
send_ldap_result: conn=1001 op=1 p=3
send_ldap_response: msgid=2 tag=101 err=0
ber_flush2: 14 bytes to sd 11
connection_get(11): got connid=1001
connection_read(11): checking for input on id=1001
ber_get_next
ber_get_next: tag 0x30 len 49 contents:
op tag 0x4a, time 1299502775
ber_get_next
conn=1001 op=2 do_delete
ber_scanf fmt (m) ber:
>>> dnPrettyNormal: <o=xxx,dc=example,dc=com>
<<< dnPrettyNormal: <o=xxx,dc=example,dc=com>, <o=xxx,dc=example,dc=com>
bdb_dn2entry("o=xxx,dc=example,dc=com")
bdb_dn2entry("o=xxx,dc=example,dc=com")
bdb_entry_get: rc=0
bdb_dn2entry("o=xxx,dc=example,dc=com")
=> bdb_dn2id_delete 0x25d3ca: "o=xxx,dc=example,dc=com"
=> bdb_idl_delete_key: c_get lo failed: DB_BUFFER_SMALL: User memory too
small for return value (-30999)
=> bdb_dn2id_delete 0x25d3ca: subtree (o=xxx,dc=example,dc=com) delete
failed: -30999
<= bdb_dn2id_delete 0x25d3ca: -30999
<=- bdb_delete: dn2id failed: DB_BUFFER_SMALL: User memory too small for
return value (-30999)
send_ldap_result: conn=1001 op=2 p=3
send_ldap_response: msgid=3 tag=107 err=80
ber_flush2: 36 bytes to sd 11
connection_get(11): got connid=1001
connection_read(11): checking for input on id=1001
ber_get_next
ber_get_next: tag 0x30 len 5 contents:
op tag 0x42, time 1299502775
ber_get_next
ber_get_next on fd 11 failed errno=0 (Success)
conn=1001 op=3 do_unbind
connection_get(11): got connid=1001
connection_get(11): got connid=1001
connection_close: conn=1001 sd=11
=============================================================================
Doing an ldapsearch for the entry takes some time, but does finish.
Looking at the -d1 output there's a lot of "bdb_search: <number> scope
not okay" messages.
There's about 5 million objects in the database. I only know of this one
object on this server which has this problem. I have another server with
another object with the same problem. Other objects can be deleted just
fine.
Looking at the slapcat output, there's only the base "o=xxx" object.
There's no subordinate objects to this object.
/Peter
10 years, 10 months
Re: (ITS#6853) slapadd/slapindex -q hang
by dhawes＠vt.edu
On 03/04/2011 05:56 PM, hyc(a)symas.com wrote:
> dhawes(a)vt.edu wrote:
>> On 03/04/2011 04:08 PM, hyc(a)symas.com wrote:
>>> This indicates that the trickle task is still waiting for a signal on its
>>> condition variable. Which is a bit odd since bdb_tool_entry_close() already
>>> signals it before slap_tool_destroy() is called.
>>>
>>> It might be illuminating to run slapadd under gdb with a breakpoint on
>>> bdb_tool_entry_close(), and singlestep through the first few lines of that
>>> function where it issues the signal, and see if the trickle task actually
>>> reacts or not.
>>
>> Setting a breakpoint on bdb_tool_entry_close() and then either
>> continuing or stepping through the function allows slapadd to exit cleanly.
>
> A fix for this is now in HEAD, please test.
> back-bdb/tools.c 1.140
>
Tested, and working. Thanks for the fix.
10 years, 10 months
Re: (ITS#6817) idassert-bind with SASL issues
by hyc＠symas.com
masarati(a)aero.polimi.it wrote:
>> 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.
>
> I understand the fix I'm suggesting can sound counter-intuitive. The
> documentation should clearly indicate that the binddn in case of SASL is
> for *local* and *internal* issues, and will not be part of the
> authentication process. As an alternative, lc_bound_ndn could receive a
> dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive
> the actual identity from the remote server using the authid control along
> with the bind or performing a whoami extop later, as already implemented).
Using a dummy DN here sounds OK.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 10 months
