Bug 107869 - slapadd creates files with unusable ownership
Summary: slapadd creates files with unusable ownership
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: openldap (Show other bugs)
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Jan Safranek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-23 21:22 UTC by John Berninger
Modified: 2007-11-30 22:06 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 19:33:45 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 John Berninger 2003-10-23 21:22:00 UTC
Description of problem:
"slapadd" creates LDAP database files with incorrect permissions

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. After OpenLDAP packages installed and slapd.conf file configured, create LDIF
2. Issue "slapadd -v -l <LDIF file>"
3. Note that files created in <LDAPDIR> (created by above slapadd command) are
owned by root - the LDAP server cannot read them.  After chown'ing the files to
ldap:ldap, the server can read them and returns results as expected.
Actual results:

Expected results:

Additional info:

Comment 1 Rich Graves 2004-04-29 12:56:01 UTC
This is not a bug. Run slapadd as user ldap.

Comment 2 John Berninger 2004-04-29 13:17:34 UTC
If I could use the "ldap" user, that would work.  In RHEL 3, you
cannot "su" to the ldap user, so this is in fact a bug.  Whether it's
a bug with the ldap user ID not being available or with the
openldap-servers package not setting the correct permissions, I'll
leave to RH Engineering.

Comment 3 Rich Graves 2004-05-03 16:56:24 UTC
I see your point.

Well, workarounds are sudo -u ldap slapadd (which works regardless of
the user's shell) or chown when done.

Comment 4 Andy Krause 2006-01-04 20:47:56 UTC
The problem with the ownership happens with FC3 and FC4 out of sudden. If you
try to copy the db4 ldap databases to a second machine, to make it run as a
replica and you start ldap, the __db** files will be owned by root:root, which
makes slapd stop. After a chown ldap:ldap it works - major problem: if ldap gets
choked due to  e.g. power failure and you have to delete the __db* files, you
always need to reassign correct ownership.

Second thing - after running yum update today on a fc3 machine, which ran as
ldap /samba dc well for months, the system has been killed in the same way.
Updated from 2.2.13 to 2.2.29.

If you setup an ldap server fresh from scratch, the ownership is well done
(ldap:ldap) - but with a running version it sucks.

There must be a problem with the init script, because until 2.2.13, this never

Greets and standby for further help


Comment 5 Andy Krause 2006-01-04 21:23:18 UTC
addition: my comment maybe a bit offtopic (cause it does not rely on slapadd
alone) - sorry for any troubles :-)

Comment 6 RHEL Product and Program Management 2007-10-19 19:33:45 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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