Red Hat Bugzilla – Bug 872784
slapcat segfaults when called form /usr/libexec/openldap/check-config.sh if /etc/openldap/slapd.d/cn=config.ldif not present
Last modified: 2013-08-01 13:17:14 EDT
Description of problem:
If one uses /etc/openldap/slapd.conf file instead of /etc/openldap/slapd.d/cn=config.ldif, on every restart of slapd, slapcat will segfault when called from /usr/libexec/openldap/check-config.sh if /etc/openldap/slapd.d/cn=config.ldif file is not present. Log has:
Nov 3 15:00:34 beauty kernel: [87410.331508] slapcat: segfault at 0 ip 00007f5c526e75f9 sp 00007fff6db855f0 error 4 in slapd[7f5c52611000+187000]
Slapd works fine and all.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Use slapd.conf.
2. Restart slapd.
3. See slapcat segfault.
Should not segfault.
You should not be using slapd.conf. :-)
Anyway, I'm unable to reproduce this problem. Please, can you attach your slapd.conf? Feel free to obfuscate any sensitive information.
(In reply to comment #1)
> You should not be using slapd.conf. :-)
At one point Fedora init scripts converted this file to cn=config system (this was a few releases ago), which then made the whole thing an unreadable mess. It seems, however, that these days slapd has no trouble actually using this static file.
The main reason I went back to slapd.conf is bug #871670. It was simply easier to experiment with it, being a plain text file.
> Anyway, I'm unable to reproduce this problem. Please, can you attach your
> slapd.conf? Feel free to obfuscate any sensitive information.
(In reply to comment #2)
> At one point Fedora init scripts converted this file to cn=config system
> (this was a few releases ago), which then made the whole thing an unreadable
> mess. It seems, however, that these days slapd has no trouble actually using
> this static file.
Maybe unreadable, but you can change the configuration without stopping the server and the configuration will be persistent. It is quite possible that the support for slapd.conf will be dropped in future by upstream.
> Sent privately.
Thanks, but I still cannot reproduce. How did you set up OpenLDAP to use slapd.conf? Have you done some changes in /etc/sysconfig/slapd, or have you just deleted slapd.d? What permissions and selinux context do you have on slapd.conf and slapd.d?
(In reply to comment #4)
> Thanks, but I still cannot reproduce. How did you set up OpenLDAP to use
> slapd.conf? Have you done some changes in /etc/sysconfig/slapd, or have you
> just deleted slapd.d? What permissions and selinux context do you have on
> slapd.conf and slapd.d?
This is what I have in /etc/sysconfig/slapd (this was carried over many, many Fedora upgrades):
SLAPD_URLS="ldap://127.0.0.1/ ldap://<NIC IP>/ ldaps://127.0.0.1 ldaps://<NIC IP>/"
/etc/openldap/slapd.d is there, but it contains no files. If I touch cn=config.ldif, there will be no segfault, but obviously, slapd will not work properly.
All SELinux contexts and permissions are default. There are no denials in audit.log.
Hope this helps:
# gdb /usr/sbin/slapcat
GNU gdb (GDB) Fedora (188.8.131.5220120-52.fc17)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
Reading symbols from /usr/sbin/slapcat...Reading symbols from /usr/lib/debug/usr/sbin/slapd.debug...done.
(gdb) set args -c -H 'ldap:///cn=config???(|(objectClass=olcBdbConfig)(objectClass=olcHdbConfig))'
Starting program: /usr/sbin/slapcat -c -H 'ldap:///cn=config???(|(objectClass=olcBdbConfig)(objectClass=olcHdbConfig))'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
# no data for entry id=00000000
Program received signal SIGSEGV, Segmentation fault.
0x000055555562a5f9 in ldif_tool_entry_next (be=<optimized out>) at ldif.c:1743
1743 Entry *e = tl->entries[ tl->ecurrent ];
Missing separate debuginfos, use: debuginfo-install keyutils-libs-1.5.5-2.fc17.x86_64 krb5-libs-1.10.2-6.fc17.x86_64 libcom_err-1.42.3-3.fc17.x86_64 libgcc-4.7.2-2.fc17.x86_64 libselinux-2.1.10-3.fc17.x86_64 nss-softokn-freebl-3.13.6-1.fc17.x86_64 zlib-1.2.5-7.fc17.x86_64
#0 0x000055555562a5f9 in ldif_tool_entry_next (be=<optimized out>)
#1 0x00005555556076ac in slapcat (argc=<optimized out>, argv=<optimized out>)
#2 0x00005555555789d1 in main (argc=<optimized out>, argv=0x7fffffffe3e8)
I can reproduce now.
Created attachment 651996 [details]
Patch to crash gracefully under described conditions.
A different patch was accepted:
I do not think this fix is critical. I will update the package when there are more fixes.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '17'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 17's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 17 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged change the
'version' to a later Fedora version prior to Fedora 17's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.