Add the ability to *disable* an existing module

[TJM]

It would be nice if there was a way to disable an existing module, like:

semodule -d openvpn

maybe something like:

selinux::module{'openvpn':
    ensure => 'disabled',
}

[vinzent]

unfortunatly there is no support in selmodule type for disable.

https://docs.puppet.com/puppet/latest/types/selmodule.html#selmodule-attribute-ensure

[vinzent]

@TJM can you describe what benefit you see to the workaround of simply removing the module? what problem would it solve for you?

please comment within the next few days if you feel this is an important feature.

[TJM]

@vinzent - MySQL is the most common example, when trying to use Galera Cluster. If you just "remove" the mysql module, then each time the selinux packages are updated, they re-install and it makes the cluster fail. The module needs to be "present" but "disabled" in order to make sure that that it doesn't "break" the cluster during package updates.

It may be such that there needs to be an "upstream" bug, or a different type/provider? I am glad that someone is "looking" at this.

Thanks, Tommy

[vinzent]

@TJM I did see galera and selinux playing nicely. needed just a small addition to the policy because of few not myql-default paths (at least if I remember correctly).

but nonetheless this sounds like a valid use case.

at least there is some hope of a solution because

$ sudo semanage module --list --locallist

Modulname                 Priorität Sprache

gear                      100       pp    Deaktiviert
sandbox                   400       pp    Deaktiviert

lists disabled modules on Fedora25. need to verify with older semanag versions.

[TJM]

We had issues with the "mysql" and "rsync" modules, come to think of it, cause Galera tries to run rsync on a "non-standard" port. CentOS 6 supports disabled modules as well..

# semanage module --list | grep Disable
mysql                    1.11.3    Disabled
rsync                    1.9.1     Disabled

[vinzent]

@TJM please comment also on #178 which is about redesigning selinux::module params.

[oranenj]

This might be quite non-trivial to implement. essentially it seems we'd have to reimplement the selmodule type entirely... Which might happen eventually, anyway, considering how buggy it currently is.

Additionally, semodule --list-modules behaves differently in newer versions which makes it harder to maintain backwards compatibility.