Bug 237417 - permissions of ldapi socket need to be world-writable
permissions of ldapi socket need to be world-writable
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openldap (Show other bugs)
5.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Jan Safranek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-22 10:10 EDT by Axel Thimm
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2007-0499
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 12:28:41 EST
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 Axel Thimm 2007-04-22 10:10:49 EDT
+++ This bug was initially created as a clone of Bug #211045 +++

Description of problem:
An ldap server has been installed and configured for hosting the user/password
database. Accessing through nss_ldap and ldapi:/// (e.g. over a socket) works
fine and gives very good performance. Turning on nscd generates timeouts of
5-10sec for each call. Turning of nscd bring is back to immediate response

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

How reproducible:
always

Steps to Reproduce:
1.Setup ldap with ldapi:///
2.Point nss_ldap to ldapi
3.Turn on nscd
4.time id something
  
Actual results:
# time id something
id: something: No such user

real    0m5.023s
user    0m0.008s
sys     0m0.008s


Expected results (e.g. w/o nscd):
# time id something
id: something: No such user

real    0m0.025s
user    0m0.004s
sys     0m0.016s


Additional info:
o Looks like it happens in FC5, too
o The logs say

Oct 17 00:05:14 fifty nscd: nss_ldap: reconnecting to LDAP server (sleeping 4
seconds)...
Oct 17 00:05:18 fifty nscd: nss_ldap: failed to bind to LDAP server
ldapi://%2fvar%2frun%2fldapi/: Can't contact LDAP server
Oct 17 00:05:18 fifty nscd: nss_ldap: reconnecting to LDAP server (sleeping 8
seconds)...
Oct 17 00:05:26 fifty nscd: nss_ldap: failed to bind to LDAP server
ldapi://%2fvar%2frun%2fldapi/: Can't contact LDAP server
Oct 17 00:05:26 fifty nscd: nss_ldap: reconnecting to LDAP server (sleeping 16
seconds)...
Oct 17 00:05:42 fifty nscd: nss_ldap: failed to bind to LDAP server
ldapi://%2fvar%2frun%2fldapi/: Can't contact LDAP server
Oct 17 00:05:42 fifty nscd: nss_ldap: reconnecting to LDAP server (sleeping 32
seconds)...
Oct 17 00:06:14 fifty nscd: nss_ldap: failed to bind to LDAP server
ldapi://%2fvar%2frun%2fldapi/: Can't contact LDAP server
Oct 17 00:06:14 fifty nscd: nss_ldap: reconnecting to LDAP server (sleeping 64
seconds)...

But still there are accesses through nss_ldap over ldapi in between. So while
there is a log that seems to timeout the connection does happen after a while
and returns the correct result.

o I've googled on nscd and ldapi and some with a similar issue seem to blame too
  many open fds. But that doesn't seem to make much sense.

Is there anything else I can offer for helping to debug this? Thanks!

-- Additional comment from Axel.Thimm@ATrpms.net on 2006-10-16 18:13 EST --
Here is a related bug report

http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=246057;msg=10

-- Additional comment from drepper@redhat.com on 2006-10-16 19:04 EST --
The nscd daemon probably does not have the permissions to talk to the ldap
daemon.  nscd uses the NSS module just like any other program.  Any difference
is an artifact of the way nscd is running.  You likely have to adjust the
permissions somehow somewhere.

-- Additional comment from Axel.Thimm@ATrpms.net on 2006-10-17 04:13 EST --
Thanks Ulrich, that was it.

For posterity: the default owner/mode of the socket are root:root 0755. Making
that root:nscd 0775 fixed it.

I don't see a way to specify ownership/mode in openldap anywhere. Maybe one
could arrange the openldap package to offer that socket with proper permissions
in advance, but I'm not sure it's worth the trouble. Closing as NOTABUG, but
feel free to move to openldap if you think it's worth hunting further. Thanks again!


-- Additional comment from Axel.Thimm@ATrpms.net on 2006-10-17 10:33 EST --
Unfortunately there is still an issue with ldapi and nscd: (re)starting slapd
removes the permissions and breaks nscd again. I'm reopening against openldap:

# ls -ld /var/run/ldapi; /etc/init.d/ldap restart; ls -ld /var/run/ldapi
srwxrwxr-x 1 root nscd 0 Oct 17 10:04 /var/run/ldapi
Stopping slapd:                                            [  OK  ]
Stopping slurpd:                                           [  OK  ]
Checking configuration files for slapd:  config file testing succeeded
                                                           [  OK  ]
Starting slapd:                                            [  OK  ]
Starting slurpd:                                           [  OK  ]
srwxr-xr-x 1 root root 0 Oct 17 16:22 /var/run/ldapi

Perhaps the init file should change

        if test x$SLAPD_LDAPI = xyes ; then
            harg="$harg ldapi:///"
        fi

to

        if test x$SLAPD_LDAPI = xyes ; then
            harg="$harg ldapi:///???x-mod=777"
        fi

Or perhaps modify group ownership/permission after starting slapd in the init
script. Thanks!

-- Additional comment from Axel.Thimm@ATrpms.net on 2006-10-17 14:04 EST --
The x-mod syntax does not work anymore, the ldap developers deactivated this in
this commit

http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/daemon.c.diff?r1=1.257&r2=1.258

The remaining options are to adjust permissions manually after starting slapd,
using umask 0, or patching the source (e.g. to always create the socket as 0777).

I'd go for the last option, because the manual chgrp/chmod only works for
hardwired socket file names and umask 0 may affect other files (replicas?)


-- Additional comment from Axel.Thimm@ATrpms.net on 2006-11-24 21:16 EST --
No comment?

-- Additional comment from Axel.Thimm@ATrpms.net on 2007-02-07 04:06 EST --
Fixed upstream in 2.3.29. Please upgrade FC6's package or use the patch at

ftp://ftp.openldap.org/incoming/ivan-nejgebauer-061012.patch

It is against 2.3.27, e.g. the version used in FC6, so it should apply cleanly.
It actually performs what had been suggested in comment #5.

-- Additional comment from Axel.Thimm@ATrpms.net on 2007-02-16 05:49 EST --
This issue is fixed with the packages in the testing queue.
Comment 1 Axel Thimm 2007-04-22 10:12:40 EDT
Please apply ftp://ftp.openldap.org/incoming/ivan-nejgebauer-061012.patch
Comment 2 RHEL Product and Program Management 2007-05-17 05:24:45 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 7 errata-xmlrpc 2007-11-07 12:28:41 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0499.html

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