Bug 1485397

Summary: sudo breaking who ldap and local users after upgrade
Product: Red Hat Enterprise Linux 7 Reporter: aheverle
Component: sudoAssignee: Daniel Kopeček <dkopecek>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: high Docs Contact:
Priority: high    
Version: 7.4CC: aheverle, apeddire, atolani, dapospis, grzegorz.g.krol, jvymazal, mike.d.koch, mlstarling31, pkis, rsroka
Target Milestone: rcKeywords: Regression, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-11-02 13:49:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description aheverle 2017-08-25 14:52:44 UTC
Description of problem:
After upgrading to the latest version of sudo, ldap and local users are not able to sudo

Version-Release number of selected component (if applicable):
sudo-1.8.19p2-10.el7.x86_64

How reproducible:
Everytime

Steps to Reproduce:
1. sudo su -

Actual results:
<username> is not in the sudoers file.  This incident will be reported.

Expected results:
Able to run sudo commands

Comment 24 grzegorz krol 2017-09-06 11:28:11 UTC
Same issue with version:
* sudo-1.8.19p2-11.el7_4.x86_64

Comment 25 grzegorz krol 2017-09-06 12:00:48 UTC
After downgrade all works:
 yum downgrade sudo-1.8.6p7-23.el7_3.x86_64

Comment 30 Daniel Kopeček 2017-09-12 08:00:09 UTC
(In reply to grzegorz krol from comment #24)
> Same issue with version:
> * sudo-1.8.19p2-11.el7_4.x86_64

Are you using the ldap or sssd backend?

Comment 32 grzegorz krol 2017-09-12 08:19:09 UTC
I'm using Dell Quest (vas4 module).

Comment 43 Michael Starling 2017-09-12 14:54:27 UTC
I see this issue with the LDAP backend. We do not use the SSSD backend because it doesn't respect the sudo option "!root_sudo". We also like to keep our standard bind user in sssd.conf different from the user that searches for SUDO rules in /etc/sudo-ldap.conf. We have also found that we are unable to restrict ACLs as tightly for the bind user in sssd.conf as we are in sudo-ldap.conf.