[kexec-tools/f20] remove 98selinux dependency

[Baoquan He]

commit 46c75849e538725cff6a73ca486dc28cd5238a0c
Author: dyoung at redhat.com <dyoung at redhat.com>
Date:   Mon Aug 12 10:52:20 2013 +0800

    remove 98selinux dependency
    
    Chaowang measured the selinux load_policy memory usage, it need ~50M
    It's too much under kdump 2nd kernel, it cause more OOM then before.
    
    Here is the findings from Vivek:
    - If we don't load policy or don't do restorecon, kernel automatically
      uses a label for file as specified by file
      /sys/fs/selinux/initial_contexts/file
    
      On my system this value is "system_u:object_r:file_t:s0". Kernel
      enforces this label on a file if it is not labeled. That's the reason
      that you see above label on vmcore file when selinux policy was not
      loaded in second kernel or restorecon was not done.
    
      Note: I did some testing with rhel6 and there also I see file_t context.
      Not sure why that's the case.
    
    - Relabeling of root file system over boot happens if there is a file
      /.autorelabel present. This file is touched by systemd service
      fedora-autorelabel-mark.service. And this file comes from initscritps
      package.
    
      So if this service thinks that system was booted with selinux disabled
      it will put this file on root and when next time system boots with
      selinux enabled, relabeling is enforced by fedora-autorelabel.service
      service.
    
    - In our case relabeling is not happening after saving vmcore because
      there does not seem be any fedora-autorelabel-mark.service running
      from initramfs context. Looks like this service runs after switching
      to real root.
    
      Aug 08 10:44:13 vm9-f19 systemd[1]: Started Mark the need to relabel after reboot.
    
    - selinux poicy is now loaded by systemd after root switch has taken
      place.
    
      Aug 08 10:44:10 vm9-f19 systemd[1]: Successfully loaded SELinux policy in 357.693ms.
    
    So now we know that why selinux relabeling is not taking place. Reason
    being that systemd service which marks the file system for autorelabeling
    does not run from initramfs context.
    
    And it might not make to run this service from initramfs context before
    switch root. In general it makes sense to first switch to root, load
    selinux policy if needed and then check whether to mark this filesystem
    for relabel or not. Ideally root is mourted read only before that. It is
    just that we break this rule for kdump. So as long as we make sure we
    relabel files created by kdump after booting back, things should be fine.
    
    Since we will relabel the vmcore dir after reboot so let's remove
    the selinux dracut module dependency to avoid load_policy in 2nd kernel.
    If in the future load_policy memory usage shrinks to an acceptable level
    or there's a better solution we can add selinux load_policy back later.
    
    Signed-off-by: Dave Young <dyoung at redhat.com>
    Acked-by: Vivek Goyal <vgoyal at redhat.com>

 dracut-module-setup.sh |    4 ----
 1 files changed, 0 insertions(+), 4 deletions(-)
---
diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
index 099c03a..517099c 100755
--- a/dracut-module-setup.sh
+++ b/dracut-module-setup.sh
@@ -15,10 +15,6 @@ check() {
 depends() {
     local _dep="base shutdown"
 
-    if sestatus 2>/dev/null | grep -q "SELinux status.*enabled"; then
-        _dep="$_dep selinux"
-    fi
-
     if [ -d /sys/module/drm/drivers ]; then
         _dep="$_dep drm"
     fi