From 59934ba188362d12483f91bb02d5fe427bc18a55 Mon Sep 17 00:00:00 2001
From: WANG Chao <chaowang@redhat.com>
Date: Tue, 26 Nov 2013 00:23:11 +0800
Subject: [PATCH] kdumpctl: Avoid leaking fd to subshell

We only allow one instance of kdump service running at each time by
flock /var/lock/kdump which is opened as fd 9 in kdumpctl script.

However a leaking fd issue has been discovered by SELinux:

When executing a specific shell command (not the shell built-in but
provided by other packages, in this case - restorecon) in kdumpctl,
current shell will fork a new subshell for executing and
the subshell will inherit open fd 9 from parent shell. And SELinux
detects that subshell is holding the open fd and consider fd 9 is
leaked.

To avoid this kind of leaking, the most easy way seems to be breaking our
kdumpctl code out into two parts:
- A top level parent shell, which is only used to deal with the lock and
  invoking the subshell below.
- A 2nd tier level subshell, which is closing the inherited open fd at
  very first and doing the rest of the kdumpctl job. So that it isn't
  leaking fd to its subshell when executing like restorecon, etc.

To be easy to understand, the callgraph is roughly like below:
[..]
--> open(9)
--> flock(9)
--> fork
  --> close(9)      <-- we close 9 right here
  --> main()        <-- we're now doing the real job
  --> [..]
  --> fork()
    --> restorecon  <-- we don't leak fd 9 to child process
  --> [..]
--> [..]

As shown above, a wrapper main() is added as the 2nd tier level shell in
this kind of call model. So we can completely avoid leaking fd to
subshell.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
---
 kdumpctl | 95 ++++++++++++++++++++++++++++++--------------------------
 1 file changed, 51 insertions(+), 44 deletions(-)

diff --git a/kdumpctl b/kdumpctl
index 358ef05..46ae633 100755
--- a/kdumpctl
+++ b/kdumpctl
@@ -543,52 +543,59 @@ if [ ! -f "$KDUMP_CONFIG_FILE" ]; then
 	exit 1
 fi
 
+main ()
+{
+	case "$1" in
+	  start)
+		if [ -s /proc/vmcore ]; then
+			save_core
+			reboot
+		else
+			start
+		fi
+		;;
+	  stop)
+		stop
+		;;
+	  status)
+		EXIT_CODE=0
+		status
+		case "$?" in
+		  0)
+			echo "Kdump is operational"
+			EXIT_CODE=0
+			;;
+		  1)
+			echo "Kdump is not operational"
+			EXIT_CODE=3
+			;;
+		  2)
+			echo "Kdump is unsupported on this kernel"
+			EXIT_CODE=3
+			;;
+		esac
+		exit $EXIT_CODE
+		;;
+	  restart)
+		stop
+		start
+		;;
+	  condrestart)
+		;;
+	  propagate)
+		propagate_ssh_key
+		;;
+	  *)
+		echo $"Usage: $0 {start|stop|status|restart|propagate}"
+		exit 1
+	esac
+}
+
 # Other kdumpctl instances will block in queue, until this one exits
 single_instance_lock
 
-case "$1" in
-  start)
-	if [ -s /proc/vmcore ]; then
-		save_core
-		reboot
-	else
-		start
-	fi
-	;;
-  stop)
-	stop
-	;;
-  status)
-	EXIT_CODE=0
-	status
-	case "$?" in
-	0)
-		echo "Kdump is operational"
-		EXIT_CODE=0
-		;;
-	1)
-		echo "Kdump is not operational"
-		EXIT_CODE=3
-		;;
-	2)
-		echo "Kdump is unsupported on this kernel"
-		EXIT_CODE=3
-		;;
-	esac
-	exit $EXIT_CODE
-	;;
-  restart)
-	stop
-	start
-	;;
-  condrestart)
-	;;
-  propagate)
-	propagate_ssh_key
-	;;
-  *)
-	echo $"Usage: $0 {start|stop|status|restart|propagate}"
-	exit 1
-esac
+# To avoid fd 9 leaking, we invoke a subshell, close fd 9 and call main.
+# So that fd isn't leaking when main is invoking a subshell.
+(exec 9<&-; main $1)
 
 exit $?