Bug 103008 - Slapadd does not set database permissions right
Summary: Slapadd does not set database permissions right
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openldap   
(Show other bugs)
Version: 4.0
Hardware: i386 Linux
Target Milestone: ---
: ---
Assignee: Jan Safranek
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-25 10:07 UTC by Zenon Panoussis
Modified: 2015-01-08 00:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-26 10:52:54 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Zenon Panoussis 2003-08-25 10:07:22 UTC
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5a) Gecko/20030718

Description of problem:
A new ldap database created with slapadd ends up with the ownership and umask of
the user running slapadd, normally 644/root:root. Slapd does not protest this,
nor has any problems starting up, but then fails on all operations. This is a
nasty trap; I had already seen two different admins fall in it before I fell in
it myself.

This was already reported against RH 7.2, see bug #56606, but was closed with
NOTABUG. Yet, it would be a Very Good Thing if someone would add a few lines of
code to slapadd to take care of the problem. Nalin, will you please consider a
patch or pass this on upstream?

Version-Release number of selected component (if applicable):
2.0.x, 2.1.x

How reproducible:

Steps to Reproduce:
1. slapadd -l file.ldif
2. service ldap start
3. ldapsearch 

Expected Results:  Databases created with the permissions and ownership of the
slapd server user, normally 600/ldap:ldap.

Comment 1 Bill Nottingham 2006-08-07 15:49:19 UTC
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running
Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core
release or Red Hat Enterprise Linux or comparable. Some information on which
option may be right for you is available at

Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks. Please check if this
issue is still present in a current Fedora Core release. If so, please change
the product and version to match, and check the box indicating that the
requested information has been provided. Note that any bug still open against
Red Hat Linux by the end of 2006 will be closed as 'CANTFIX'. Thanks again for
your help.

Comment 2 Zenon Panoussis 2006-08-07 16:47:34 UTC
Still present in RHEL 4.3

Comment 3 Zenon Panoussis 2006-08-07 17:09:33 UTC
Correction: the permissions are now set right, 0600, but the ownership is not,
so 600/root:root still prevents slapd from reading its db. The problem is
however mitigated by the initscript, which nowadays prints warnings:

# service ldap start
/var/lib/ldap/id2entry.bdb is not owned by "ldap"          [WARNING]
/var/lib/ldap/dn2id.bdb is not owned by "ldap"             [WARNING]
/var/lib/ldap/objectClass.bdb is not owned by "ldap"       [WARNING]
Checking configuration files for : config file testing succeeded
Starting slapd:                                            [  OK  ]

The last line is wrong, starting slapd actually failed, but this should still be
enough for any admin to realise what's wrong and fix it manually. Whether to
close the bug as is or fix slapadd to set the ownership is a question of quality
standards, not for me to decide. 

Comment 4 Jan Safranek 2007-10-26 10:52:54 UTC
I am going to close it - warnings are displayed, user should know what to do.
Users can call slapadd from various reasons and they do not expect it will set
permissions to the database.

Note You need to log in before you can comment on or make changes to this bug.