Bug 103008 - Slapadd does not set database permissions right
Slapadd does not set database permissions right
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openldap (Show other bugs)
4.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jan Safranek
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-25 06:07 EDT by Zenon Panoussis
Modified: 2015-01-07 19: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-26 06:52:54 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 Zenon Panoussis 2003-08-25 06:07:22 EDT
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:
Always

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 11:49:19 EDT
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
http://www.redhat.com/rhel/migrate/redhatlinux/.

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 12:47:34 EDT
Still present in RHEL 4.3
Comment 3 Zenon Panoussis 2006-08-07 13:09:33 EDT
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 06:52:54 EDT
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.