Bug 782162 - configfiles shouldn't be mandatory executable
Summary: configfiles shouldn't be mandatory executable
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mkinitrd
Version: 5.7
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Brian Lane
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-16 17:18 UTC by Andreas Piesk
Modified: 2012-01-19 01:13 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-19 01:13:59 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.