Bug 1397169

1. Proposed title of this feature request  
    Sudo to include "maxseq" & "ignore_iolog_errors" option.
      
2. Who is the customer behind the request?  
    Account name: First National Bank
    Account number: 	818530
      
    TAM customer: no 
    SRM customer: no  
    Strategic: yes  
      
3. What is the nature and description of the request?  
   In sudo 1.8.18 there is a new sudoers setting, ignore_iolog_errors, that will allow sudo to continue running when the I/O log cannot be written to.

4. Why does the customer need this? (List the business requirements here)  
      
Customer require the feature for their security solution. Currently they lack proper auditing in the manner they and the auditors want. That is recorded playback like session for any shared accounts, (like root, oracle etc) where multiple unique users `sudo su -` to. The sudoreplay function addresses this need.

Unfortunately, sudoreplay can not log to a remote syslog. Therefore they need to log to a directory. The problem they have is that for security/audit reasons they deny any access to root unless it is via sudo. sudo will and can stop working when the sudoreplay is enabled and fills up the directory. The result is that sudo completely stops working. This creates business impact and service downtime which the business obviously can not afford. In such a scenario the above two features help by:

5. How would the customer like to achieve this? (List the functional requirements here)  
- MaxSeq, allows one to keep a specified amount of data and rotate it, hence not filling up a FS.
- ignore_iolog_errors allows to ignore any io errors when the sudoreplay directory fills up. Or in, our case, the remote share that the sudoreplay logs are writing to is inaccessible. We would have to log to a mounted remote directory so we can centralise these logs, as sudoreplay doesn't allow logging via syslog.

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

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?  
N.A
      
8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?  
RHEL-7.4
     
9. Is the sales team involved in this request and do they have any additional input?  
N.A
   
10. List any affected packages or components.  
 sudo-1.8.6p7-20.el7
     
11. Would the customer be able to assist in testing this functionality if implemented?
Yes