Bug 1350828 - [RHEL7] visudo ignores -q flag
Summary: [RHEL7] visudo ignores -q flag
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sudo
Version: 7.3
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: ---
Assignee: Daniel Kopeček
QA Contact: Stefan Kremen
URL:
Whiteboard:
Depends On: 1197885
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-06-28 13:24 UTC by Stefan Kremen
Modified: 2016-11-03 20:33 UTC (History)
7 users (show)

Fixed In Version: sudo-1.8.6p7-20.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1197885
Environment:
Last Closed: 2016-11-03 20:33:15 UTC
Target Upstream Version:


Attachments (Terms of Use)
proposed patch (470 bytes, patch)
2016-07-19 14:02 UTC, Daniel Kopeček
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2593 normal SHIPPED_LIVE Low: sudo security, bug fix, and enhancement update 2016-11-03 12:10:56 UTC

Description Stefan Kremen 2016-06-28 13:24:44 UTC
+++ This bug was initially created as a clone of Bug #1197885 +++

Description of problem:
visudo ignores the -q (quiet) option and prints out syntax errors.

Version-Release number of selected component (if applicable):
sudo-1.8.6p3-15.el6.x86_64
Also in the version present in RHEL 7.0

How reproducible:
Any sort of syntax error or warning present in sudoers file.  As an example:
Remove a ")" resulting in a syntax error:
## Same thing without a password
%wheel  ALL=(ALL        NOPASSWD: ALL


Steps to Reproduce:
1. Create syntax error in /etc/sudoers
2. Run 'visudo -c -q'


Actual results:
visudo -c -q
visudo: >>> /etc/sudoers: syntax error near line 108 <<<
parse error in /etc/sudoers near line 108


Expected results:
No output, with an exit value of 1


Additional info:
Based on a code review it does not appear to be honoring the '-q' flag         
at all:                                                                        
                                                                               
It's initialized to false to start:                                            
/*                                                                             
     * Arg handling.                                                           
     */                                                                        
    checkonly = oldperms = quiet = strict = false;                             
                                                                               
Then when the args get parsed:                                                 
case 's':                                                                      
        strict = true;      /* strict mode */                                  
        break;                                                                 
        case 'q':                                                              
        quiet = false;      /* quiet mode */                                   
                                                                               
                                                                               
quiet doesn't appear to ever be set to true.                                   
                                                                               
                                                                               
Found some upstream references that this flag was broken in 1.8.6,             
which both RHEL 6 and RHEL 7 are based off.

Comment 2 Daniel Kopeček 2016-07-19 14:02:17 UTC
Created attachment 1181645 [details]
proposed patch

Comment 6 errata-xmlrpc 2016-11-03 20:33:15 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.

https://rhn.redhat.com/errata/RHSA-2016-2593.html


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