Bug 789937

Summary: [RFE] Add ability to treat files authoritatively in sudoers.ldap
Product: Red Hat Enterprise Linux 6 Reporter: J.H.M. Dassen (Ray) <rdassen>
Component: sudoAssignee: Daniel Kopeček <dkopecek>
Status: CLOSED ERRATA QA Contact: Aleš Mareček <amarecek>
Severity: high Docs Contact:
Priority: high    
Version: 6.4CC: amarecek, csuleski, dkopecek, dpal, dspurek, dsulliva, jduncan, ksrot, pvrabec, rbinkhor
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: 6.4   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: sudo-1.8.6p3-1.el6 Doc Type: Release Note
Doc Text:
Treating Matches Authoritatively in Look Ups of sudoers Entries The sudo utility is able to consult the /etc/nsswitch.conf file for sudoers entries and look them up in files or in LDAP. Previously, when a match was found in the first database of sudoers entries, the look up operation still continued in other databases (including files). In Red Hat Enterprise Linux 6.4, an option was added to the /etc/nsswitch.conf file that allows users to specify a database after which a match of a sudoers entry is sufficient. This eliminates the need to query any other databases; thus, improving the performance of sudoers entry look ups in large environments. This behavior is not enabled by default and must be configured by adding the [SUCCESS=return] string after a selected database. When a match is found in a database that directly precedes this string, no other databases are queried.
Story Points: ---
Clone Of:
: 840097 (view as bug list) Environment:
Last Closed: 2013-02-21 09:44:08 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:    
Bug Blocks: 554476, 607248, 703952, 772279, 782183, 806907, 840699    

Description J.H.M. Dassen (Ray) 2012-02-13 10:18:35 UTC
3. What is the nature and description of the request?

Sudo currently can be configured to consult the nsswitch.conf file for
sudoers entries and look up via files and ldap. If a match is found in the
first database, it still continues to look for matches in the second
database. The customer would like the ability to treat a match in the first
database (such as files) authoritatively--returning without executing a
query on a expensive secondary database (such as ldap).


4. Why does the customer need this? (List the business requirements here)

 Customer has a large environment with thousands of sudoers records and
netgroups.  Since migrating to ldap sudo has become a major performance
issue. However, because of the “unusual” (compared with libc) way sudo works
when it is configured multiple repositories performance is terrible.  Even
if sudo finds a positive match authorizing a command in local files, it will
always continue and, if the authorization is via a netgroup (which is their
standard), all netgroups referenced in all sudoers records will be looked
up. They anticipate that the proposed change could reduce server load by
over 90% and reduce response times by 90% compared with today’s
configuration.  They anticipate that this would cause a major reduction in
dissatisfaction of our users in the current ldap/RHEL environment compared
with our NIS/Solaris environment.


5. How would the customer like to achieve this? (List the functional
requirements here)

They suggest adding a return if successful operation to sudoers.ldap to be
specified like:
   sudoers: files [SUCCESS=return] ldap
This would skip the ldap db lookup if files find a successful match. They
have provided a suggested patch to implement this feature.


6. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

 With the configuration addition specified above, if a sudoers match is
found in files, an ldap query should not be triggered. If there is no
match, we expect to see an ldap lookup.


7. Is there already an existing RFE upstream or in Red Hat bugzilla?

None found


8. Does the customer have any specific timeline dependencies?

ASAP


9. Is the sales team involved in this request and do they have any
additional input?

No


10. List any affected packages

sudo


11. Would the customer be able to assist in testing this functionality if
implemented?

Yes

Comment 4 Jake Kodak 2012-04-28 03:35:04 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. This request will be considered in a future release of Red Hat Enterprise Linux.

Comment 20 errata-xmlrpc 2013-02-21 09:44:08 UTC
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-2013-0363.html