Bug 985608 - Request that the bootstrap/deploy script check /etc/sudoers for the includedir line
Request that the bootstrap/deploy script check /etc/sudoers for the includedi...
Status: CLOSED WONTFIX
Product: otopi
Classification: oVirt
Component: RFEs (Show other bugs)
---
Unspecified Linux
unspecified Severity urgent (vote)
: ---
: ---
Assigned To: Alon Bar-Lev
Haim
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-17 17:10 EDT by Michael Everette
Modified: 2016-02-10 14:38 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-08 06:30:04 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 426683 None None None Never

  None (edit)
Description Michael Everette 2013-07-17 17:10:17 EDT
Description of problem:

Customer had custom /etc/sudo file that was causing Panic: Couldn't connect to supervdsm issues when trying to connect a new RHEL host to RHEV-M

Version-Release number of selected component (if applicable):

RHEV 3.2.1 
vdsm-4.10.2-23.0.el6ev.x86_64

How reproducible:

very

Steps to Reproduce:
1. remove the following lines from sudoers file:
## Read drop-in files from /etc/sudoers.d (the # here does not mean a comment)
#includedir /etc/sudoers.d
2. try to connect new host to RHEV-M


Actual results:
Host can not be added
Comment 1 Vincent Danen 2013-07-17 19:30:12 EDT
This doesn't strike me as a security problem.  It's a configuration problem.  I imagine there is something important in the /etc/sudoers.d/ directory that is no longer being referenced because the customer removed that includedir directive.  They should really be looking to see if there is something necessary in there before removing configuration directives (somewhat like Apache won't necessarily work well if you start removing its config files too).
Comment 2 Dan Kenigsberg 2013-08-04 16:59:06 EDT
(In reply to Vincent Danen from comment #1)
> I imagine there is something important in the /etc/sudoers.d/ directory that
> is no longer being referenced...

Indeed, vdsm puts /etc/sudoers.d/50_vdsm there, and cannot work without this file being inlined by sudo.

It makes sense that ovirt-host-deploy fails installation if it cannot find the "#includedir" line in /etc/sudoers. However, there are uncountable other host (mis)configurations which are equally capable of killing vdsm. I am in favor of fixing this one mostly because older sudoers files used to lack #includedir, so enterprises may like it.
Comment 3 Alon Bar-Lev 2013-08-04 17:12:44 EDT
ovirt-host-deploy is not system validation tool. It cannot check every single component for validity. We do not have the resources to write system validation tool.

Administrator should not remove system drop dirs, he can add his own, but he is own his own when removing.

I do not know when /etc/sudoers.d was not included by default in rhel, however, host-deploy did not touch sudoers configuration, so there is no known issue here.

I tend to close this as WONTFIX.
Comment 4 Alon Bar-Lev 2013-08-08 06:30:04 EDT
If sysadmin modify its system to ignore basics/documented locations, he is responsible for any breakage. Modifying sudo configuration is one example, another is modify logrotage, or even the /etc/profile in a way that will conflict with software, or change the /etc/security or rename the root user.

The role of ovirt-host-deploy is to simplify host installation, not be AI and try to guess if manual changes of admin can effect the outcome.

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