Hi!

There is a typo on step 3:

sed -i "s/^SELINUX=.*/SELINUX=disable/g" /etc/selinux/config 

The correct is:

sed -i "s/^SELINUX=.*/SELINUX=disabled/g" /etc/selinux/config

Sorry!

> It happens because the option '--alloptions' force the 'sosreport' to enable 
> all plugins and the SELinux plugin does not detect that the SELinux is 
> disabled.

No: --alloptions sets every boolean *plugin option* to True, as it says in the man page:

       -a, --alloptions
              Set all boolean options to True for all enabled plug-ins.

It does not have any effect on plugin enablement; the SELinux plugin (like most) is enabled when its packages list is satisfied:

class SELinux(Plugin, RedHatPlugin):
[...]
    packages = ('libselinux',)

So it'll run on any system with libselinux installed regardless of whether SELinux is active or not.

This is intended as it means that configuration and diagnostic information is captured even when SELinux is disabled or in permissive mode.

The plugin doesn't run setfiles itself; it calls 'fixfiles' when the selinux.fixfiles plugin option is True.

Given that it seems that this is a problem in `fixfiles` when run with SELinux disabled; we could work around this in sos by not calling it when that is the case but I think it would be better to fix it at source: `fixfiles` should exit with an error if SELinux is off rather than continuing to call 'setfiles'.

sosreport should check inside fo the SELinux plugin.

Not fixfiles problem.

/usr/lib/python3.4/site-packages/sos/plugins/selinux.py should check if SELinux is enabled

python -c "import selinux; print(selinux.is_selinux_enabled())"
1

How come fixfiles can't just do something like that and exit with a reasonable status or error message?

I know it's a shell script but it's still trivial to check the SELinux status.

[root@bmr-rhel6-vm1 ~]# getenforce 
Disabled
[root@bmr-rhel6-vm1 ~]# fixfiles check
usage:  /sbin/setfiles [-dnpqvW] [-o filename] [-r alt_root_path ] spec_file pathname...
usage:  /sbin/setfiles -c policyfile spec_file
usage:  /sbin/setfiles -s [-dnpqvW] [-o filename ] spec_file

Entirely independently of sos that is a _really_ confusing error; what did I do wrong? And why is setfiles talking to me?

There's nothing to tell me it's just because SELinux is disabled (unless I already know that).

I would like to see something like:

[root@bmr-rhel6-vm1 ~]# getenforce 
Disabled
[root@bmr-rhel6-vm1 ~]# fixfiles check
SELinus is disabled.
[root@bmr-rhel6-vm1 ~]# echo $?
1
[root@bmr-rhel6-vm1 ~]#

S/Linus/Linux/

Ok, I can see that.

But sosreport is still going to be doing other SELinux checks which should probably not do.

Agreed - we've not had other reports of problems so far but I've filed an issue upstream to go through and audit this:

https://github.com/sosreport/sos/issues/605

The fix would be quite easy:

--- /sbin/fixfiles.orig 2015-07-22 11:49:19.733659820 +0200
+++ /sbin/fixfiles      2015-07-22 12:06:32.008337081 +0200
@@ -140,6 +140,11 @@
 # if called with -n will only check file context
 #
 restore () {
+if ! selinuxenabled; then
+       echo $"SELinux is disabled."
+       exit 1
+fi
+
 if [ ! -z "$PREFC" ]; then
     diff_filecontext $*
     exit $?
@@ -192,6 +197,11 @@
 }
 
 relabel() {
+    if ! selinuxenabled; then
+        echo $"SELinux is disabled."
+        exit 1
+    fi
+
     if [ ! -z "$RPMFILES" ]; then
        restore 
     fi

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/RHBA-2016-0791.html