tag 367716 confirmed patch
found 367716 2.1~rc4-2
kthxbye
On Wed, May 17, 2006 at 17:22:45 -0400, Andres Salomon wrote:
> I noticed the following on my system:
>
> [EMAIL PROTECTED]:~# lsof -ni |grep 1199
> zebra 11348 quagga 6u IPv4 1833114 UDP *:1199
> ospfd 11352 quagga 6u IPv4 1833114 UDP *:1199
> openvpn 11354 root 6u IPv4 1833114 UDP *:1199
> [EMAIL PROTECTED]:~# grep 1199 /etc/openvpn/003-rowdy-to-kale.conf
> port 1199
> [EMAIL PROTECTED]:~# grep ^up /etc/openvpn/003-rowdy-to-kale.conf
> up "/bin/sh -e /etc/init.d/quagga restart; echo"
> up-restart
> [EMAIL PROTECTED]:~# /etc/init.d/quagga restart
> Stopping Quagga daemons (prio:0): (waiting) .. ospfd (waiting) . zebra
> (bgpd) (ripd) (ripngd) (ospf6d) (isisd).
> Removing all routes made by zebra.
> Nothing to flush.
> Loading capability module if not yet done.
> Starting Quagga daemons (prio:10): zebra ospfd.
> [EMAIL PROTECTED]:~# lsof -ni |grep 1199
> openvpn 11354 root 6u IPv4 1833114 UDP *:1199
> [EMAIL PROTECTED]:~#
>
>
> My system is configured to restart quagga whenever an openvpn tunnel
> goes up or down. It would appear that whenever openvpn spawns a
> process, it inherits its file descriptors (including the listening
> socket). This is pretty bad. you can see from the lsof that it's fd 6
> that openvpn is listening on; if I shut down that tunnel without killing
> quagga, I cannot start the tunnel again because processes (quagga) are
> still "listening" on that port. I imagine there's all kinds of
> additional problems that this could cause.
>
I noticed the same problem. openvpn sets the FD_CLOEXEC flag
on sock->fd in socket.c:link_socket_init_phase2(), with this comment:
/* set socket file descriptor to not pass across execs, so that
scripts don't have access to it */
But, looking at init.c:init_instance(), the call sequence is
...
do_init_socket_1();
do_open_tun();
do_init_socket_2();
...
link_socket_init_phase2() is called from do_init_socket_2(), and the
'up' script is run by do_open_tun(), *before* the CLOEXEC flag is set,
so the script end up with the listening socket open, and you lose.
Moving the set_cloexec() call from link_socket_init_phase2() to
link_socket_init_phase1() should fix this.
Cheers,
Julien
diff -u openvpn-2.1~rc4/debian/changelog openvpn-2.1~rc4/debian/changelog
--- openvpn-2.1~rc4/debian/changelog
+++ openvpn-2.1~rc4/debian/changelog
@@ -1,3 +1,12 @@
+openvpn (2.1~rc4-2.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * If we want the 'up' scripts not to inherit our socket, setting the
+ FD_CLOEXEC flag *after* running the scripts turns out not to work.
+ Closes: #367716.
+
+ -- Julien Cristau <[EMAIL PROTECTED]> Sat, 05 Apr 2008 18:38:40 +0200
+
openvpn (2.1~rc4-2) unstable; urgency=low
* Upload to unstable. New upstream fixes:
only in patch2:
unchanged:
--- openvpn-2.1~rc4.orig/socket.c
+++ openvpn-2.1~rc4/socket.c
@@ -1253,6 +1253,10 @@
resolve_bind_local (sock);
resolve_remote (sock, 1, NULL, NULL);
}
+
+ /* set socket file descriptor to not pass across execs, so that
+ scripts don't have access to it */
+ set_cloexec (sock->sd);
}
/* finalize socket initialization */
@@ -1459,10 +1463,6 @@
/* set socket to non-blocking mode */
set_nonblock (sock->sd);
- /* set socket file descriptor to not pass across execs, so that
- scripts don't have access to it */
- set_cloexec (sock->sd);
-
#ifdef ENABLE_SOCKS
if (socket_defined (sock->ctrl_sd))
set_cloexec (sock->ctrl_sd);
