Bug 211045 - permissions of ldapi socket need to be world-writable
permissions of ldapi socket need to be world-writable
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
6
All Linux
medium Severity high
: ---
: ---
Assigned To: Jan Safranek
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-16 18:11 EDT by Axel Thimm
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: openldap-2.3.30-2.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-18 04:11:20 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 Axel Thimm 2006-10-16 18:11:16 EDT
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!
Comment 1 Axel Thimm 2006-10-16 18:13:42 EDT
Here is a related bug report

http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=246057;msg=10
Comment 2 Ulrich Drepper 2006-10-16 19:04:04 EDT
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.
Comment 3 Axel Thimm 2006-10-17 04:13:48 EDT
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!
Comment 4 Axel Thimm 2006-10-17 10:33:27 EDT
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!
Comment 5 Axel Thimm 2006-10-17 14:04:09 EDT
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?)
Comment 6 Axel Thimm 2006-11-24 21:16:10 EST
No comment?
Comment 7 Axel Thimm 2007-02-07 04:06:22 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.
Comment 8 Axel Thimm 2007-02-16 05:49:04 EST
This issue is fixed with the packages in the testing queue.
Comment 9 Jan Safranek 2007-05-18 04:11:20 EDT
openldap-2.3.30-2.fc6 has been pushed for fc6, which should resolve this issue.
 If these problems are still present in this version, then please make note of
it in this bug report.

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