Bug 782162

Summary: configfiles shouldn't be mandatory executable
Product: Red Hat Enterprise Linux 5 Reporter: Andreas Piesk <andreas.piesk>
Component: mkinitrdAssignee: Brian Lane <bcl>
Status: CLOSED NOTABUG QA Contact: Release Test Team <release-test-team>
Severity: low Docs Contact:
Priority: unspecified    
Version: 5.7CC: ddumas
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-19 01:13:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Andreas Piesk 2012-01-16 17:18:33 UTC
Description of problem:

configfiles /etc/sysconfig/mkinitrd/* must be executable to be sourced in by /sbin/mkinitrd which is not necessary. they will be silently ignored if they are not executable.

Version-Release number of selected component (if applicable):

5.1.19.6-71.el5_7.1

How reproducible:

always

Steps to Reproduce:
1.disable building ramdisk with DMRAID by creating a file /etc/sysconfig/mkinitrd/dmraid with content "DMRAID=no" and permissions 644
2.create a ramdisk. mkinitrd will try to find all dmraid devices which can take a lot of time in SAN-environments.
3.
  
Actual results:

mkinitrd tries to detect dmraid devices even with DMRAID=no

Expected results:

mkinitrd ignores dmraid devices if DMRAID=no specified

Additional info:

fix is trivial, just check for readable instead of executable:

--
$ diff -Pur mkinitrd mkinitrd.mod 
--- mkinitrd	2011-11-14 23:30:37.000000000 +0100
+++ mkinitrd.mod	2012-01-16 18:09:42.000000000 +0100
@@ -57,7 +57,7 @@
 CFG_DIR=${MKINITRD_CONFIG_DIR:-/etc/sysconfig/mkinitrd}
 cfgs="$CFG_DIR/*[^~]"
 for cfg in $cfgs ; do
-    [ -x $cfg ] && . $cfg
+    [ -r $cfg ] && . $cfg
 done
 
 CONFMODS="$MODULES"
--

Comment 1 Brian Lane 2012-01-19 01:13:59 UTC
While I do agree, I don't see any reason to change this at this point. There could very well be people who use -x to disable scripts, as silly as that sounds I don't want to take the chance that it could cause problems for those who have come to expect the current behavior.