Bug 107869 - slapadd creates files with unusable ownership
slapadd creates files with unusable ownership
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: openldap (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jan Safranek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-23 17:22 EDT by John Berninger
Modified: 2007-11-30 17:06 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:33:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Berninger 2003-10-23 17:22:00 EDT
Description of problem:
"slapadd" creates LDAP database files with incorrect permissions

Version-Release number of selected component (if applicable):
openldap-servers-2.0.27-11

How reproducible:
Immediately

Steps to Reproduce:
1. After OpenLDAP packages installed and slapd.conf file configured, create LDIF
file.
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 08:56:01 EDT
This is not a bug. Run slapadd as user ldap.
Comment 2 John Berninger 2004-04-29 09:17:34 EDT
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 12:56:24 EDT
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 15:47:56 EST
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
happened.

Greets and standby for further help

Andy
Comment 5 Andy Krause 2006-01-04 16:23:18 EST
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 15:33:45 EDT
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:
http://www.redhat.com/security/updates/errata/
 
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.