Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 593242 - nss_ldap does not handle "unreadable" certificate files when resolving usernames and groups and using TLS.
nss_ldap does not handle "unreadable" certificate files when resolving userna...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: nss_ldap (Show other bugs)
5.5
All Linux
medium Severity medium
: rc
: ---
Assigned To: Nalin Dahyabhai
Ondrej Moriš
:
Depends On: 609722 811468
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-18 06:00 EDT by Sander
Modified: 2012-10-15 04:01 EDT (History)
6 users (show)

See Also:
Fixed In Version: nss_ldap-253-46.el5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-02-21 01:38:43 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)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0268 normal SHIPPED_LIVE nss_ldap bug fix and enhancement update 2012-02-20 10:06:24 EST

  None (edit)
Description Sander 2010-05-18 06:00:36 EDT
Description of problem:

nss_ldap does not handle "unreadable" certificate files when resolving usernames and groups and using TLS.

Version-Release number of selected component (if applicable):
nss_ldap-253-25.el5

How reproducible:
Configure ldap authentication with TLS encryption and a cacert-directory. Login, place an unreadable file in this directory, login again and observe the problem.

Steps to Reproduce:
1. Configure ldap authentication with TLS encryption and a cacert-directory (e.g. /etc/openldap/cacerts)
2. Create a not world-readable file in this directory (e.g. touch /etc/openldap/cacerts/test ; chmod 0 /etc/openldap/cacerts/test
3. Login with a LDAP-user
  
Actual results:
[root@server ~]# su - ldapuser
id: cannot find name for user ID 10001
id: cannot find name for group ID 10009
id: cannot find name for group ID 10009
id: cannot find name for user ID 10001
[I have no name!@server ~]$ id
uid=10001 gid=10009 groups=10(wheel),10001,10009 context=root:system_r:unconfined_t:SystemLow-SystemHigh
[I have no name!@server ~]$ 

Expected results:
[root@server ~]# su - ldapuser
[ldapuser@server ~]$ id
uid=10001(ldapuser) gid=10009(ldapgroup) groups=10(wheel),10001(extra_ldap_group),10009(ldapgroup) context=root:system_r:unconfined_t:SystemLow-SystemHigh
[ldapuser@server ~]$

Additional info:

* The getent group and getent passwd commands also fail to display the ldap users.

Excerpt from an strace of the failing su - command:

======================
[pid  7493] open("/etc/openldap/cacerts", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 4
[pid  7493] fcntl(4, F_SETFD, FD_CLOEXEC) = 0
[pid  7493] getdents(4, /* 5 entries */, 32768) = 152
[pid  7493] open("/etc/openldap/cacerts/test", O_RDONLY) = -1 EACCES (Permission denied)
[pid  7493] close(4)                    = 0
[pid  7493] write(3, "0\5\2\1\2B\0", 7) = 7
[pid  7493] shutdown(3, 2 /* send and receive */) = 0
[pid  7493] close(3)                    = 0
[pid  7493] shutdown(4294967295, 2 /* send and receive */) = -1 EBADF (Bad file descriptor)
[pid  7493] close(4294967295)           = -1 EBADF (Bad file descriptor)
[pid  7493] stat("/etc/ldap.conf", {st_mode=S_IFREG|0644, st_size=9185, ...}) = 0
[pid  7493] geteuid()                   = 10001
[pid  7493] open("/etc/hosts", O_RDONLY) = 3
[pid  7493] fcntl(3, F_GETFD)           = 0
[pid  7493] fcntl(3, F_SETFD, FD_CLOEXEC) = 0
[pid  7493] fstat(3, {st_mode=S_IFREG|0644, st_size=362, ...}) = 0
[pid  7493] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2af6ed2dd000
=========================

* Dangling symlinks in the cacert-directory have an even worse effect: the su - commando fails completely:

[root@server ~]# su - ldapuser
su: user ldapuser does not exist
[root@server ~]#
Comment 1 Dmitri Pal 2010-05-18 08:33:00 EDT
In this case the cert is not readable by anybody including the nss_ldap module. It is unclear what expectation do you have? It is definitely wrong to expect that nss_ldap would work if the cert is not readable.
Comment 2 Sander 2010-05-18 10:01:37 EDT
There is a valid certificate in the directory, adding a file that is not world readable (chmod 0640 is sufficient) causes TLS to stop working. (while the original certificate is still readable).

My expectation in this case would be for for nss_ldap to ignore the unreadable file(s) and use the readable one(s).
Comment 3 Dmitri Pal 2010-05-18 10:43:18 EDT
(In reply to comment #2)
> There is a valid certificate in the directory, adding a file that is not world
> readable (chmod 0640 is sufficient) causes TLS to stop working. (while the
> original certificate is still readable).
> 
> My expectation in this case would be for for nss_ldap to ignore the unreadable
> file(s) and use the readable one(s).    

Ok thanks for the clarification. Now it makes more sense.
Comment 4 Nalin Dahyabhai 2010-06-30 18:04:35 EDT
The place this needs to be fixed is actually openldap's libldap.  Opening a bug against that component and marking it as a blocker of this one.  

Once that's fixed, we need rebuild against it to pick up the fix in nss_ldap, which is why I'm not simply reassigning it.
Comment 6 RHEL Product and Program Management 2011-01-11 15:15:59 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 14 Jakub Hrozek 2011-10-21 07:39:38 EDT
nss_ldap-253-46.el5 BuildRequires openldap >= 2.3.43-20 and was rebuilt against -23
Comment 17 errata-xmlrpc 2012-02-21 01:38:43 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0268.html

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