Improve slapd postinst error message in case database directory can't be determined for a given LDAP suffix

[Mike Bernson]

Bug is due to buggy configuration, but we could have a better error message. See comment 5 for details.

Original description:
When doing a apt-get dist-upgrade going from slapd_2.4.15-1ubuntu3_amd64.deb to slapd_2.4.15-1ubuntu3.1_amd64.deb
I get the following output:
batch@work-isp:/tmp$ sudo apt-get dist-upgrade
[sudo] password for batch:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]? y
Setting up slapd (2.4.15-1ubuntu3.1) ...
  Backing up /etc/ldap/slapd.conf in /var/backups/slapd-2.4.15-1ubuntu3... done.
chown: invalid argument: `'
dpkg: error processing slapd (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 slapd
E: Sub-process /usr/bin/dpkg returned an error code (1)

output of lsb_release -rd:
batch@work-isp:/tmp$ lsb_release -rd
Description: Ubuntu 9.04
Release: 9.04

output of apt-cache policy slapd:
batch@work-isp:/tmp$ apt-cache policy slapd
slapd:
  Installed: 2.4.15-1ubuntu3.1
  Candidate: 2.4.15-1ubuntu3.1
  Version table:
 *** 2.4.15-1ubuntu3.1 0
        500 http://us.archive.ubuntu.com jaunty-updates/main Packages
        500 http://security.ubuntu.com jaunty-security/main Packages
        100 /var/lib/dpkg/status
     2.4.15-1ubuntu3 0
        500 http://us.archive.ubuntu.com jaunty/main Packages

I except the package to install without error.

The package did not install correct leaves the sysem with
1 not fully installed or removed

[Marc Deslauriers (mdeslaur)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

[Mike Bernson (mike-mlb)]

This is a security problem because it stop an package which has security problems from being updated.

Package: slapd (2.4.15-1ubuntu3.1) [security]

from package changelog:

openldap (2.4.15-1ubuntu3.1) jaunty-security; urgency=low

  * SECURITY UPDATE: null ptr deref, free uninitialized data in modrdn calls
    - openldap-2.4.22-CVE-2010-0211-modrdn_check_error.patch:
      - check return for errors and clean up uninitialized data
    - openldap-2.4.22-CVE-2010-0212-modrdn_null_deref.patch:
      - return error on 0-length or binary RDNs
    - CVE-2010-0211, CVE-2010-0212

 -- Steve Beattie <email address hidden> Wed, 28 Jul 2010 23:28:31 -0700

[Nathan Stratton Treadway (nathanst)]

I wonder if the cause of this "chown" error is at all related to the one discussed in bug #450645 ....

If you can post the output of the following commands it might provide enough information to figure out what exactly is triggering the bug:

  $ sudo sh -c "ls -l /etc/ldap/slapd.d/cn=config/olcDatabase*"

  $ sudo sh -c "grep olcSuffix: /etc/ldap/slapd.d/cn=config/olcDatabase*"
and
  $ sudo sh -c "grep olcDbDirectory: /etc/ldap/slapd.d/cn=config/olcDatabase*"

[Mike Bernson (mike-mlb)]

batch@work-isp:~$ sudo sh -c "ls -l /etc/ldap/slapd.d/cn=config/olcDatabase*"
ls: cannot access /etc/ldap/slapd.d/cn=config/olcDatabase*: No such file or directory

batch@work-isp:~$ sudo sh -c "grep olcSuffix: /etc/ldap/slapd.d/cn=config/olcDatabase*"
grep: /etc/ldap/slapd.d/cn=config/olcDatabase*: No such file or directory

batch@work-isp:~$ sudo sh -c "grep olcDbDirectory: /etc/ldap/slapd.d/cn=config/olcDatabase*"
grep: /etc/ldap/slapd.d/cn=config/olcDatabase*: No such file or directory

batch@work-isp:~$ ls /etc/ldap
data ldap.conf ldap.doc sasl2 schema slapd.conf

batch@work-isp:~$ ls -R /etc/ldap
/etc/ldap:
data ldap.conf ldap.doc sasl2 schema slapd.conf

/etc/ldap/data:
aa data.ldif.try1 data.ldif.try3 intervivaz.ldif
data.ldif data.ldif.try2 data.ldif.try4 reload

/etc/ldap/sasl2:

/etc/ldap/schema:
amavis.schema core.schema inetorgperson.schema nis.schema
authldap.schema cosine.ldif java.schema openldap.ldif
authldap.schema.orig cosine.schema misc.ldif openldap.schema
collective.schema duaconf.schema misc.schema pmi.schema
corba.schema dyngroup.schema nadf.schema ppolicy.schema
core.ldif inetorgperson.ldif nis.ldif README

ldap.conf:
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE dc=example,dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never

slapd.conf:
include /etc/ldap/schema/core.schema
##include /etc/ldap/schema/collective.schema
##include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
##include /etc/ldap/schema/duaconf.schema
##include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
##include /etc/ldap/schema/java.schema
#include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
##include /etc/ldap/schema/openldap.schema
##include /etc/ldap/schema/ppolicy.schema
##include /etc/ldap/schema/pmi.schema
#include /usr/local/etc/ldap/samba.schema
#include /usr/local/etc/ldap/sq_prefs.schema
#include /usr/local/etc/ldap/squirrelmail.schema.OpenLDAP-2.1.x
include /etc/ldap/schema/authldap.schema

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid

# List of arguments that were passed to the server
argsfile /var/run/slapd/slapd.args
# Read slapd.conf(5) for possible values
#loglevel none
#loglevel filter stats
loglevel stats
#loglevel 32767

# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_hdb
moduleload syncprov

# The maximum number of entries that is returned for a search operation
sizelimit 5000

# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1

# specific Backend Directives for hdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
database hdb
suffix "dc="domain"
rootdn "cn=admin,dc...

[Nathan Stratton Treadway (nathanst)]

Ah, okay, you are still using the slapd.conf file, rather than the slapd.d configuration directory, so your error and the one in #450645 are more like cousins than siblings :)

> # Backend specific directives apply to this backend until another
> # 'backend' directive occurs
> database hdb
> suffix "dc="domain"
> rootdn "cn=admin,dc=domain"
> rootpw "{SSHA}<some text for a password>"
> directory "/var/lib/ldap"

Does the "suffix' line in our slapd.conf file really have three double-quote characters in it? If so, I suspect that's the trigger in your case...

Specifically, when the postinst script builds the list of suffixes to process, it looks for lines that start with "suffix" and then removes *all* the " characters from the value string found -- so when it goes back to find the directory whose permissions need to be updated, it is looking for a line that says:
   suffix "dc=domain"

This doesn't match the actual existing line,
   suffix "dc="domain"
, and so the search fails. In this case, the get_directory() function call would return an empty string, and when "chown" is called with that empty string as the target path, it would return the
   invalid argument: `'
error message.

[Mike Bernson (mike-mlb)]

changing suffix "dc="domain" to suffix "dc=domain" fixed the problem.

Not sure why nothing in ldap/slapd thinks this is a problem but thing look
to be working.

[Nathan Stratton Treadway (nathanst)]

It occured to me that when the postinst script is unable to determine the database directory associated with a particular suffix (for whatever reason), simply producing the error message "chown: invalid argument: `'" and then aborting isn't very helpful to the system administrator.

Here's a patch that checks the result of the get_directory function call, and if no directory is returned prints a descriptive warning rather than trying to set permissions on <nothing>.

The patch only changes the update_database_permissions() function, so it should be an improvement regardless of whether slapd.conf or slapd.d-style configuration is in use.

This version of the patch simply prints a warning message and continues processing the rest of the postinst run, on the theory the there's a good chance that everything will still work fine even if we don't run this particular "missing" chown command -- but if there is actually a need to abort the installation in that situation, the patch could easily be tweaked to print an appropriate message and then exit with an error status instead.