Bug 580094 - Suggested man-pages change for nsswitch.conf
Summary: Suggested man-pages change for nsswitch.conf
Status: CLOSED DUPLICATE of bug 583644
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: sudo
Version: 5.5
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Daniel Kopeček
QA Contact: BaseOS QE Security Team
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-07 13:27 UTC by Issue Tracker
Modified: 2010-11-09 12:45 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-09-14 14:41:35 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Issue Tracker 2010-04-07 13:27:49 UTC
Escalated to Bugzilla from IssueTracker

Comment 1 Issue Tracker 2010-04-07 13:27:50 UTC
Event posted on 04-07-2010 09:14am EDT by kbaxley

The customer ran into a problem after updating to the latest version of nss_ldap in RHEL5.5:


At first it looked as if there was some sort of regression in the latest revision of 
nss_ldap. The customer was getting reports from the field (approx. 125 affected 
systems) that were using LDAP to distribute sudoers information using the 
sudoers_base    ou=SUDOers,dc=unix,dc=lanl,dc=gov directive. 
When they 
got upgraded to the latest nss_ldap release ( nss_ldap-253-25.el5 
the sudo functionality broke.

Cannot sudo when configured to use LDAP for sudoers information.

Attempt to use sudo responds with "User not in /etc/sudoers. This 
incident will be reported." failure message.

Expected Behavior:
User able to execute sudo without error.

Work Around:
Uninstall latest nss_ldap libraries and install previous version 
(nss_ldap-253-22 for RHEL 5).

A later update from the customer found that this apparently was an undocumented change in behavior rather than a regression:
This is just a follow up on our saga with getting sudo back and working 
on our systems. Turns out that I identified the wrong library as the 
issue. We are now using all of the latest rel 5 updates with no 
problems. The issue was that an entry in nsswitch.conf is required now. 
We added the line (sudoers: files ldap) to cfengine and now we can sudo 
again! BTW, we never found this in the documentation, just took a wild 
guess and it worked.

Perhaps a clean up or updating of the documentation for nsswitch.conf is 
in order?
This event sent from IssueTracker by kbaxley  [LANL]
 issue 732073

Comment 7 Need Real Name 2010-05-06 23:49:56 UTC
Our hosts were bitten by this as well.  I finally found the documentation for this new behavior here:


but this change was not mentioned in any of the errata notes for sudo packages in RHN.

It appears to also be buried in the /usr/share/doc/sudo-1.7.2p1/sudoers.ldap.pod file, but that's not the first place that I would think to go spelunking.

The reference in the README.LDAP file states:

    See the "Configuring nsswitch.conf" section in the sudoers.ldap manual for details.

I initially presumed that meant "man 5 sudoers.ldap" and looked for an installed man page with that information.  It is certainly not mentioned in sudoers(5).

Perhaps the most sane thing is to incorporate running pod2man on that file during the RPM build to round out the documentation set where most admins will think to go looking for it.  At initial glance, that is the only main documentation file that is not already installed in /usr/share/man.

Comment 8 Need Real Name 2010-05-07 01:09:59 UTC
BTW, This looks like it's the other side of the coin of 583644.

Comment 9 Ivana Varekova 2010-07-14 09:02:21 UTC
/usr/share/doc/sudo-1.7.2p1/sudoers.ldap.pod is part of sudo package, so reassigning to it.

Comment 11 Daniel Kopeček 2010-09-14 14:41:35 UTC
Closing this as duplicate of #583644. Installation of the missing sudoers.ldap man-page will be solved as part of that bug. Sorry for the inconvenience.

*** This bug has been marked as a duplicate of bug 583644 ***

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