Bug 1034333

Ahh, and fwiw:

system-config-kdump-2.0.14-1.fc20.noarch

Thank you for your report.

The presence of this error message implies that s-c-k was unable to determine your bootloader. I'm wondering which boot loader are you using?

Could you please run the following command to check whether the configuration files are where s-c-k is expecting them?

ls -l /boot/grub/grub.conf /boot/efi/EFI/redhat/grub.conf /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg /boot/efi/EFI/fedora/grub.cfg /boot/etc/yaboot.conf /boot/efi/EFI/redhat/elilo.conf /etc/zipl.conf /boot/extlinux/extlinux.conf

Also, please make sure there are no denials for access vectors involving s-c-k and bootloader configuration files by SELinux.

I'm using grub2 and the config files are in the normal spot.

Please look again at the screenshot. The problem is that the tool is running this:

    grubby -- --info ALL

...instead of:

    grubby --info ALL

Yes, s-c-kdump is supposed to run

    grubby --$bootloadertype --info ALL

however it seems that bootloader detection fails and empty string is appended to the double dash. This already happened, e.g. in bug #983017.

Does your system boot via UEFI? Can you please confirm that this happens with SELinux in permissive mode as well?

No UEFI. Mine's a standard BIOS boot rig.

Yes, setting SELinux into permissive mode seems to work around the problem. So I guess this is a policy issue?

Here are the AVC messages too:

type=AVC msg=audit(1385477285.036:237): avc:  denied  { search } for  pid=20191 comm="system-config-k" name="grub2" dev="md1" ino=16 scontext=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir
type=SYSCALL msg=audit(1385477285.036:237): arch=c000003e syscall=21 success=no exit=-13 a0=199ab00 a1=2 a2=32df3bff88 a3=0 items=0 ppid=20190 pid=20191 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="system-config-k" exe="/usr/bin/python2.7" subj=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1385477285.036:238): avc:  denied  { search } for  pid=20191 comm="system-config-k" name="extlinux" dev="md1" ino=8193 scontext=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir
type=SYSCALL msg=audit(1385477285.036:238): arch=c000003e syscall=21 success=no exit=-13 a0=194d490 a1=2 a2=32df3bff88 a3=0 items=0 ppid=20190 pid=20191 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="system-config-k" exe="/usr/bin/python2.7" subj=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 key=(null)

I think syscall=21 means that these were access() calls...

That would make sense, s-c-kdump detects the bootloader by checking access(bootloader_config, W_OK).

I tried to reproduce the bug in current F20 but hit what looks like entirely different bug.

I'm going to reassign this to selinux-policy - I suppose the maintainers would like to know:
1) version of selinux-policy
2) what does the AVC look like including paths, which you can enable by running

    # echo "-w /etc/shadow -p w" >> /etc/audit/audit.rules
    # systemctl restart auditd

   and then reproducing the bug again.

Note: the paths that s-c-kdump checks are listed here: https://git.fedorahosted.org/cgit/system-config-kdump.git/tree/src/system-config-kdump-backend.py#n19

Ahh, I figured out the problem. My /boot filesystem was mislabeled:

"/boot/extlinux default label should be boot_t."

Sorry for the noise!