Red Hat Bugzilla – Bug 985608
Request that the bootstrap/deploy script check /etc/sudoers for the includedir line
Last modified: 2016-02-10 14:38:56 EST
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):
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)
2. try to connect new host to RHEV-M
Host can not be added
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).
(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.
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.
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.