Bug 688771 - nslcd works with SSL/TLS in debug mode only
Summary: nslcd works with SSL/TLS in debug mode only
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: nss-pam-ldapd
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 784976 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-17 23:38 UTC by Ondrej Moriš
Modified: 2013-02-14 02:06 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-14 02:06:02 UTC
Type: ---


Attachments (Terms of Use)
Reproducer (192.29 KB, application/x-bzip2)
2011-03-17 23:38 UTC, Ondrej Moriš
no flags Details

Description Ondrej Moriš 2011-03-17 23:38:02 UTC
Created attachment 486124 [details]
Reproducer

Description of problem:

When SSL/TLS is enabled in nss-pam-ldapd and service nslcd is not started in debug mode (i.e. with option -d), then SSL/TLS does not work. In debug mode it works fine.

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

nss-pam-ldapd-0.7.5-3.el6

How reproducible:

Steps to Reproduce:

1. Install beakerlib
2. Execute attached test: bash runtest.sh
   + test will setup slapd listening on both ldap:// and ldaps:// 
   + configure nss-pam-ldapd to use TLS
   + query server via getent
  
Actual results:

Query fails (exit code 2). 

Expected results:

Query pass (exit code 0).

Additional info:

If 'service nslcd start' is replaced by '/usr/sbin/nslcd', it still does not work. But if '/usr/sbin/nslcd -d' is used, then query passes.

Comment 1 Ondrej Moriš 2011-03-17 23:39:01 UTC
Version-Release number of selected component (if applicable):

nss-pam-ldapd-0.7.7-1.fc14.i686

Comment 2 Nalin Dahyabhai 2011-07-27 19:29:11 UTC
The test appears to be setting permissions on the CA certificate (/etc/openldap/cacerts/cacert.pem) to ldap:ldap, 0400.  The nslcd service is configured to run as nslcd:ldap, which can't read files with those permissions.  A failure to verify the server's certificate with "tls_reqcert demand" should cause the connection attempt to fail.  So this appears to be a configuration error.

Comment 3 lejeczek 2012-01-26 19:55:08 UTC
@Nalin

not for me, my cacert is 644, besides if nslcd ran from command line it still reads conf file and switches over to the user defined there

on f16 version nss-pam-ldapd-0.7.13-7.fc16.x86_64 suffers from identical failure but it's SElinux fault

Comment 4 Nalin Dahyabhai 2012-01-26 20:13:59 UTC
(In reply to comment #3)
> not for me, my cacert is 644, besides if nslcd ran from command line it still
> reads conf file and switches over to the user defined there

Is this with the F14 package, or the F16 package?
 
> on f16 version nss-pam-ldapd-0.7.13-7.fc16.x86_64 suffers from identical
> failure but it's SElinux fault

How so?

Comment 5 Daniel Walsh 2012-01-26 22:53:42 UTC
Please provide AVC messages.

Comment 6 Daniel Walsh 2012-01-26 22:54:27 UTC
*** Bug 784976 has been marked as a duplicate of this bug. ***

Comment 7 lejeczek 2012-01-27 16:22:05 UTC
how does boolean authlogin_nsswitch_use_ldap matter here and to nslcd?
is it explained somewhere amongst man pages?
it seems like a fix?

Comment 8 Daniel Walsh 2012-01-27 16:54:50 UTC
authlogin_nsswitch_use_ldap means the getpw call is going directly to ldap, versus using sssd to get to the ldap server.  

Would nslcd need to contact ldap outside of using getpw calls?

Comment 9 Daniel Walsh 2012-01-27 20:56:43 UTC
960b0d607692cc34949e439c585955fc5ac46d80 fixes this in Rawhide,  Needs to be back ported.

Comment 10 lejeczek 2012-01-27 23:31:10 UTC
no sssd on my f16 and this boolean when true indeed fixes the problem with nslcd, although audit2why mentions of this one - allow_ypbind - too,
nslcd itself a very much standard installation/configuration

Comment 11 Fedora End Of Life 2013-02-14 02:06:06 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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