Bug 593242
| Summary: | nss_ldap does not handle "unreadable" certificate files when resolving usernames and groups and using TLS. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Sander <bugzilla> |
| Component: | nss_ldap | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED ERRATA | QA Contact: | Ondrej Moriš <omoris> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.5 | CC: | bugzilla, dpal, dspurek, jhrozek, jplans, omoris |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | nss_ldap-253-46.el5 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-21 06:38:43 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 609722, 811468 | ||
| Bug Blocks: | |||
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. 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). (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. 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. 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. nss_ldap-253-46.el5 BuildRequires openldap >= 2.3.43-20 and was rebuilt against -23 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 |
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 ~]#