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