date:20161206

Re: [Openvpn-devel] [PATCH applied] Arm inotify only in server mode

2016-12-06 Thread David Sommerseth

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

ACK.  Also tested using the reproducer in Trac.  This patch
fixes the issue when OpenVPN is built using --enable-async-push.

Your patch has been applied to the master branch.

commit 7084a3993fa35c6fb71abe8aac7b30f442205e2a
Author: Lev Stipakov
Date:   Wed Dec 7 01:45:51 2016 +0200

 Arm inotify only in server mode

 Trac: #786
 Signed-off-by: Lev Stipakov 
 Acked-by: David Sommerseth 
 Message-Id: <1481067951-28917-1-git-send-email-lstipa...@gmail.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13415.html
 Signed-off-by: David Sommerseth 


- --
kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJYR342AAoJEIbPlEyWcf3ysysP/jfNdapMwuRJ8hhqJFMOvMzg
ss+EOhWpZHzC7RJfBUeYWVdXMMGL+I8beKGZTHoC1DEPkVOV4wg2FHB0wpvIQMja
BrEo/AiCBUrMC5eiIn8IO6b6ATKQih/oD07GcECcSZ0/Vica3goP1hVik7JUkAZA
2fsDjGh+5g4KfObHMaTjpID9UfQV7wsPU/C2pWc0ywq51CZXingWQnWwaYKS93OZ
i7EKxQrWy0Nxs0YhzloVI/2k6mcwwP0mzeZdQ+imhjtuXoYmSisXxUSNDrwvgYUN
byMb4qhcuuDRquR3mRO0jjVR7nlL68NDlX57Z60ocbxskZBzhfxMM1/CkXgVLC5L
TBU6IHaTWn/5/d4jo4aA50sDBQohu73Yf4/SnqwcWURsui4yJCejVQTFeKyKPxiD
CQ1T0n9swXRsgYqsKioZHv3Mywaciq5y3+3BpJ9oGg9mfYcoQxQ5kJNY6jjIYC3C
xQiFFP92bqi7d761bKhwsJU//DZ4FRwqWihhkUL9VJ4WhZmVdrJjYEcyknnRPm1F
/Woc9V2sBhIZ00VCfvu0WNvLb1w40q6PV695uqfOQzjhPuhXp3q0ZEOp76ArqZqN
OW6DjKodACCZKkSP2Ef1/9jsmXmL/46348FVBSa4Qbr7PNRlHe1LjTYQSg/aS1y4
T33QanBd0sAGstvfuf2C
=Lcf0
-END PGP SIGNATURE-

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] systemd: Intermediate --chroot fix with the new sd_notify() implementation

2016-12-06 Thread David Sommerseth

Commit c5931897ae8d663e7e introduced support for talking directly
to the systemd service manager about the situation for the OpenVPN
tunnel. This approach makes a lot of sense and is mostly the proper
way to do it.  But it was discovered that it breaks OpenVPN
configurations using --chroot.

The reason sd_notify() calls fails when using chroot() is that
sd_notify() expects to have access to a file as declared in the
$NOTIFY_SOCKET environment variable.  It is the main systemd
instance which is responsible to provide both the environment variable
as well as the socket file sd_nodify() should use.  When --chroot
comes into play, the $NOTIFY_SOCKET file will not be available
for OpenVPN any more.

As things are getting close to the 2.4_rc2 release we will not dare
to bring a too invasive fix.  As well we need some time to discuss
an approrpriate solution.  So this intermediate fix will only
provide a "successful start" message to the systemd service manager
right before chroot() happens.  This will at least resolve the issue
in a safe and non-intrusive way.

Signed-off-by: David Sommerseth 
---
 src/openvpn/init.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 74f1139..e47f0d4 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -967,7 +967,27 @@ do_uid_gid_chroot (struct context *c, bool no_delay)
   if (c->options.chroot_dir)
{
  if (no_delay)
-   platform_chroot (c->options.chroot_dir);
+{
+#ifdef ENABLE_SYSTEMD
+  /* If OpenVPN is started by systemd, the OpenVPN process needs
+   * to provide a preliminary status report to systemd.  This is
+   * needed as $NOTIFY_SOCKET will not be available inside the
+   * chroot, which sd_notify()/sd_notifyf() depends on.
+   *
+   * This approach is the simplest and the most non-intrusive
+   * solution right before the 2.4_rc2 release.
+   *
+   * TODO: Consider altnernative solutions - bind mount?
+   * systemd does not grok OpenVPN configuration files, thus cannot
+   * have a sane way to know if OpenVPN will chroot or not and to
+   * which subdirectory it will chroot into.
+   */
+  sd_notifyf(0, "READY=1\n"
+"STATUS=Entering chroot, most of the init completed 
successfully\n"
+"MAINPID=%lu", (unsigned long) getpid());
+#endif
+  platform_chroot (c->options.chroot_dir);
+}
  else if (c->first_time)
msg (M_INFO, "NOTE: chroot %s", why_not);
}
-- 
1.8.3.1


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Arm inotify only in server mode

2016-12-06 Thread Lev Stipakov

Async-push is a server side feature and inotify_fd is
initialized in server mode.

Trac #786
---
 src/openvpn/forward.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index b50a2e0..4502e10 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -1578,7 +1578,8 @@ io_wait_dowork (struct context *c, const unsigned int 
flags)
 
 #ifdef ENABLE_ASYNC_PUSH
   /* arm inotify watcher */
-  event_ctl (c->c2.event_set, c->c2.inotify_fd, EVENT_READ, 
(void*)&file_shift);
+  if (c->options.mode == MODE_SERVER)
+event_ctl (c->c2.event_set, c->c2.inotify_fd, EVENT_READ, 
(void*)&file_shift);
 #endif
 
   /*
-- 
1.9.1


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Fix wrong configure.ac parsing of --enable-async-push

2016-12-06 Thread David Sommerseth

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Your patch has been applied to the master branch

This patch was slightly modified at commit time, changed from
spaces to tabs on the line being modified.

commit e62eccf025aa60ec268787d2aa4a46310ed1cd60
Author: David Sommerseth
Date:   Tue Dec 6 23:10:51 2016 +0100

 Fix wrong configure.ac parsing of --enable-async-push

 Trac: #786
 Signed-off-by: David Sommerseth 
 Acked-by: Lev Stipakov 
 Message-Id: <1481062251-18349-1-git-send-email-dav...@openvpn.net>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13411.html


- --
kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJYR0D1AAoJEIbPlEyWcf3ym5EP/iURkTasby0UMLpy7MgwKCHD
YU8f7Kp5wPkWWiqKiOD9299DeSN/2CBBwUk7eUFZnx2FLnmU0pwUeTJpyMxuRLNj
Od2nEXetvUo3QDDDefrqNY5qkKKlYyzIO1YKCTroVCeuPlAj4ESCSH4KbytjBDIw
jm/hz8xyymCip/A/hM7/r8ioBGB+Oxp9i5dH5fDuxjWOCe0PzarXGAtOLNtIz47p
5LDuKzgxvieo1dzzSeCFNOgCOuTZrPGj6ZLbjced3lyRMMY7JbTbQBNCL9IcAjEp
n2x4hMyM884gRtgxp+lx3e4KWU0kufVW3Llf4Xj5kXmiimlgmwQ1svNyTCt6MI5M
rvoa0h9m/3/ryHUtUohVvBKjANqH+t01ePfDw9/fvHv8vcdALmA4kURpsmu0N5W4
SKx/dF6O8PW3YPTWhoW/sO7W60QGIpBUjwkxGwb2GEsehKoB0cHo1a+M26ZxD5T2
qJfS5cAGsFNLxneVNVCyHdHVN7demiwSxUqCkAIgpBhq5EIeEUtpl3V1MEzJ0Ldr
2jWOjbTMl25Znw1qfTxSblSTje5WiK5vLrdgjTGX2MUEDkHMtbd/DHWvazl0dt7G
2soxwViKwTPY+0wdC1UKnr4LIR9xyzOS1EoUJvsz9PmVVN2wljuN0twdOQ63JM9b
xRUIcWrHe0qFKH1M0J/a
=22On
-END PGP SIGNATURE-

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Correctly state the default dhcp server address in man page

2016-12-06 Thread Selva Nair

Hi,

On Tue, Dec 6, 2016 at 3:33 PM, Gert Doering  wrote:

> I'm going to merge your documentation patch now, for 2.4.0 and 2.3.14,
> but for git master we should revisit this piece of , get rid of
> "dhcp_masq_custom_offset" *and* make it default to 0 for both tun
> and tap...  (since there is no difference that the windows side of things
> can see, if .0 works in tap mode, I can't see a reason why it would not
> work in windows' "tun" mode).
>

Yes, it does work in tun mode (easy to test just use offset 0 on command
line)

I had posted a patch ( a year ago?) which sets the offset to 0. I did not
remove the offset variable though it makes sense to get rid of it... Anyway
the patch never got any attention :)

Thanks,

Selva
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix wrong configure.ac parsing of --enable-async-push

2016-12-06 Thread Lev Stipakov

ACK from me

Tested with --disable-async-push, #define does not appear.

2016-12-07 0:10 GMT+02:00 David Sommerseth :

> AC_ARG_ENABLE() was used wrong, which led enable_async_push to
> always be set, regardless if --enable-async-push or --disable-async-push
> was used.
>
> Also spotted the exact same patch when writing this commit message as
> GitHub PR#70.
>
> Trac: #786
> Signed-off-by: David Sommerseth 
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index f4073d0..c6c5fa9 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -267,7 +267,7 @@ AC_ARG_ENABLE(
>  AC_ARG_ENABLE(
> [async-push],
> [AS_HELP_STRING([--enable-async-push], [enable async-push support
> @<:@default=no@:>@])],
> -   [enable_async_push="yes"],
> +,
> [enable_async_push="no"]
>  )
>
> --
> 1.8.3.1
>
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>



-- 
-Lev
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Fix wrong configure.ac parsing of --enable-async-push

2016-12-06 Thread David Sommerseth

AC_ARG_ENABLE() was used wrong, which led enable_async_push to
always be set, regardless if --enable-async-push or --disable-async-push
was used.

Also spotted the exact same patch when writing this commit message as
GitHub PR#70.

Trac: #786
Signed-off-by: David Sommerseth 
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index f4073d0..c6c5fa9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -267,7 +267,7 @@ AC_ARG_ENABLE(
 AC_ARG_ENABLE(
[async-push],
[AS_HELP_STRING([--enable-async-push], [enable async-push support 
@<:@default=no@:>@])],
-   [enable_async_push="yes"],
+,
[enable_async_push="no"]
 )
 
-- 
1.8.3.1


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] fuzz testing by google ?

2016-12-06 Thread Gert Doering

Hi,

On Fri, Dec 02, 2016 at 08:48:29AM +0500,  ?? wrote:
> https://opensource.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html

This is generally interesting, of course.

Fuzzing openvpn "as a whole" is quite complicated, though - we do check
our input very well, so the last time someone tried to fuzz TLS packets
to make openvpn "do bad things", all he got was "go away, you stink,
session destroyed" :-)

Anyway - so what's necessary to make this google fuzz testing work?  Do
we instrument our code, or just tell them "hey, here's a useful piece
of software, go figure it out yourself"?

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] FreeBSD port versions (was: [PATCH applied] Re: Repair topology subnet on FreeBSD 11)

2016-12-06 Thread Gert Doering

Hi,

On Sat, Nov 12, 2016 at 05:43:56AM +0100, Matthias Andree wrote:
> Am 11.11.2016 um 23:10 schrieb Gert Doering:
> > I might be tempted to do a quick 2.3.14 release in between - there's two
> > important platform fixes in that branch now (FreeBSD and OpenBSD topology
> > subnet :-) ) and Lev's recursive routing patch.  Add to that the windows
> > block-outside-dns patch that I hope to be testing this weekend, and it's
> > worth a minor bugfix release...  at least "before January".
> 
> Well, for me to update the FreeBSD port, mid December 2016 would be cool
> for anything (2.3.14, or 2.4.0, or both) due to the before-xmas-madness
> and to have like two weeks for smoke testing.

Here we go :-) - Nikolaus present, 2.3.14.

2.4_beta2 is waiting for someone to bump the openvpn-devel port, but
everyone is busy, it seems (PR#214930).

I wonder what the best approach towards 2.4 in ports would be, though -
introduce an openvpn23 port, and bump "openvpn" to 2.4.0 when that
happens?  Or introduce it as "openvpn24"?

"operating system wise", 2.4.0 should be as good on FreeBSD as 2.3.14
(because all the platform fixes went into both branches), but there
might be hidden bugs lurking in the "non-client, non-platform" bits
that are new in 2.4

> Bottom line, give Debian the priority, and while it would be nice to
> have for FreeBSD, no need to rush.

So far we've managed to keep to our timeline, which currently says
"2.4_rc2 next week, and 2.4.0 end of the year" (two weeks of testing
phase for rc2)

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: Correctly state the default dhcp server address in man page

2016-12-06 Thread Gert Doering

ACK.  Because it makes documentation match code.

(This particular part of code needs to get some sanity, but this won't
happen before 2.4.0)

Your patch has been applied to the master and release/2.3 branch.

commit 251cc8f2042cc0cb8281230f7fb33f2cdec5b809 (master)
commit a1b9e4c1ac4ea1ebccf485ba2eaeb9745ef88cae (release/2.3)
Author: Selva Nair
Date:   Fri Dec 2 14:42:09 2016 -0500

 Correctly state the default dhcp server address in man page

 Signed-off-by: Selva Nair 
 Acked-by: Gert Doering 
 Message-Id: <1480707729-19578-1-git-send-email-selva.n...@gmail.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13387.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Correctly state the default dhcp server address in man page

2016-12-06 Thread Gert Doering

HI,

On Fri, Dec 02, 2016 at 02:42:09PM -0500, Selva Nair wrote:
> Also correct the default ifconfig-pool end in docs and comments
> 
> Signed-off-by: Selva Nair 
> ---
>  doc/openvpn.8| 4 ++--
>  src/openvpn/helper.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)

"why oh why"...

options.c:
  o->tuntap_options.dhcp_masq_offset = 0;   /* use network address as intern

tun.c:
  /* At what IP address should the DHCP server masquerade at? */
  if (tt->type == DEV_TYPE_TUN)
{
  if (tt->topology == TOP_SUBNET)
{
  if (tt->options.dhcp_masq_custom_offset)
ep[2] = dhcp_masq_addr (tt->local, tt->remote_netmask, tt->optio
ns.dhcp_masq_offset);
  else
ep[2] = dhcp_masq_addr (tt->local, tt->remote_netmask, -1);
}

"if no offset was specified, do not use the default setting of the variable,
as the code suggest, but use -1 instead, which conflicts with both man
page and code documentation"

But it goes on...

  else
{
  ASSERT (tt->type == DEV_TYPE_TAP);
  ep[2] = dhcp_masq_addr (tt->local, tt->adapter_netmask, tt->options.dh
cp_masq_custom_offset ? tt->options.dhcp_masq_offset : 0);
}

"except if it's a TAP device, in which case we actually *do* use the
same value that this was initialized to, namely, 0".

I'm going to merge your documentation patch now, for 2.4.0 and 2.3.14,
but for git master we should revisit this piece of , get rid of 
"dhcp_masq_custom_offset" *and* make it default to 0 for both tun 
and tap...  (since there is no difference that the windows side of things
can see, if .0 works in tap mode, I can't see a reason why it would not
work in windows' "tun" mode).

... or why we can't just use route-gateway for this...

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de

signature.asc
Description: PGP signature
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3] Refactor setting close-on-exec for socket FDs

2016-12-06 Thread Arne Schwabe

Am 06.12.16 um 13:26 schrieb Gert Doering:
> The existing code can leak socket FDs to the "--up" script, which is
> not desired.  Brought up by Alberto Gonzalez Iniesta, based on debian
> bug 367716.
> 
> Since different sockets get create at different times, just moving the
> set_cloexec() to link_socket_init_phase1() is not good enough - so move
> the call into create_socket_(), so we will catch ALL socket
> creations, no matter when or under which conditions they will be
> created (SOCKS proxy socket, listening socket, ...).

Patch looks good. ACK from me. I also looked at the port-share code path
but that part isn't touched by this commit.

Arne


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v3] Refactor setting close-on-exec for socket FDs

2016-12-06 Thread Gert Doering

The existing code can leak socket FDs to the "--up" script, which is
not desired.  Brought up by Alberto Gonzalez Iniesta, based on debian
bug 367716.

Since different sockets get create at different times, just moving the
set_cloexec() to link_socket_init_phase1() is not good enough - so move
the call into create_socket_(), so we will catch ALL socket
creations, no matter when or under which conditions they will be
created (SOCKS proxy socket, listening socket, ...).

--inetd gets an extra fd_cloexec() call, as socket FD is inherited.

URL: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367716

v2: remove set_cloexec() calls from manage.c

v3: add set_cloexec() calls to accept()ed TCP/unix child sockets

Signed-off-by: Gert Doering 
---
 src/openvpn/manage.c |  2 --
 src/openvpn/socket.c | 34 +++---
 2 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index 77a8006..e8ec442 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -1499,7 +1499,6 @@ man_new_connection_post (struct management *man, const 
char *description)
   struct gc_arena gc = gc_new ();
 
   set_nonblock (man->connection.sd_cli);
-  set_cloexec (man->connection.sd_cli);
 
   man_connection_settings_reset (man);
 
@@ -1640,7 +1639,6 @@ man_listen (struct management *man)
* Set misc socket properties
*/
   set_nonblock (man->connection.sd_top);
-  set_cloexec (man->connection.sd_top);
 
 #if UNIX_SOCK_SUPPORT
   if (man->settings.flags & MF_UNIX_SOCK)
diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index c233f2b..ce53ee8 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -771,6 +771,10 @@ create_socket_tcp (struct addrinfo* addrinfo)
   }
 #endif
 
+  /* set socket file descriptor to not pass across execs, so that
+ scripts don't have access to it */
+  set_cloexec (sd);
+
   return sd;
 }
 
@@ -815,6 +819,11 @@ create_socket_udp (struct addrinfo* addrinfo, const 
unsigned int flags)
 }
 }
 #endif
+
+  /* set socket file descriptor to not pass across execs, so that
+ scripts don't have access to it */
+  set_cloexec (sd);
+
   return sd;
 }
 
@@ -968,6 +977,12 @@ socket_do_accept (socket_descriptor_t sd,
   openvpn_close_socket (new_sd);
   new_sd = SOCKET_UNDEFINED;
 }
+  else
+{
+  /* set socket file descriptor to not pass across execs, so that
+scripts don't have access to it */
+  set_cloexec (sd);
+}
   return new_sd;
 }
 
@@ -1617,6 +1632,7 @@ link_socket_init_phase1 (struct link_socket *sock,
   ASSERT (sock->info.proto != PROTO_TCP_CLIENT);
   ASSERT (socket_defined (inetd_socket_descriptor));
   sock->sd = inetd_socket_descriptor;
+  set_cloexec (sock->sd);  /* not created by create_socket*() */
 }
   else if (mode != LS_MODE_TCP_ACCEPT_FROM)
 {
@@ -1677,13 +1693,6 @@ phase2_set_socket_flags (struct link_socket* sock)
   /* 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);
-
-  if (socket_defined (sock->ctrl_sd))
-set_cloexec (sock->ctrl_sd);
-
   /* set Path MTU discovery options on the socket */
   set_mtu_discover_type (sock->sd, sock->mtu_discover_type, sock->info.af);
 
@@ -3476,6 +3485,11 @@ create_socket_unix (void)
 
   if ((sd = socket (PF_UNIX, SOCK_STREAM, 0)) < 0)
 msg (M_ERR, "Cannot create unix domain socket");
+
+  /* set socket file descriptor to not pass across execs, so that
+ scripts don't have access to it */
+  set_cloexec (sd);
+
   return sd;
 }
 
@@ -3516,6 +3530,12 @@ socket_accept_unix (socket_descriptor_t sd,
 
   CLEAR (*remote);
   ret = accept (sd, (struct sockaddr *) remote, &remote_len);
+  if ( ret >= 0 )
+{
+  /* set socket file descriptor to not pass across execs, so that
+scripts don't have access to it */
+  set_cloexec (ret);
+}
   return ret;
 }
 
-- 
2.7.3


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] Topics for the upcoming (Wednesday, 7th Dec 2016) community meeting

2016-12-06 Thread Samuli Seppänen

Hi,

We're going to have an IRC meeting on Wednesday 7th December 2016. The 
meeting begins at 20:00 CET (19:00 UTC) on #openvpn-meeting  
irc.freenode.net. You do not have to be logged in to Freenode to join 
the channel.

Current topic list along with basic information is here:



If you have any other things you'd like to bring up, respond to this 
mail, send me mail privately or add them to the list yourself.

In case you can't attend the meeting, please feel free to make comments 
on the topics by responding to this email or to the summary email sent 
after the meeting. Whenever possible, we'll also respond to existing, 
related email threads.

--
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Refactor setting close-on-exec for socket FDs

2016-12-06 Thread Alberto Gonzalez Iniesta

On Mon, Dec 05, 2016 at 09:05:04PM +0100, Gert Doering wrote:
> Hi,
> 
> On Mon, Dec 05, 2016 at 08:01:14PM +0100, Alberto Gonzalez Iniesta wrote:
> > The patch, after being adjusted to the new source, is not working anymore:
> > 
> > Mon Dec  5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad 
> > file descriptor (errno=9)
> > Mon Dec  5 19:39:34 2016 Set FD_CLOEXEC flag on file descriptor failed: Bad 
> > file descriptor (errno=9)
> 
> This is with "the debian patch", or with my alternate suggestion?
> 
> (I'm not sure if my patch is actually good enough as I think it's not
> fixing TCP "after accept" sockets yet - but some sort of initial feedback
> would be good :) )
> 
> gert

So sorry Gert, I didn't notice yours. I' try it and let you know about
the result.


-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Arm inotify only in server mode

[Openvpn-devel] [PATCH] systemd: Intermediate --chroot fix with the new sd_notify() implementation

[Openvpn-devel] [PATCH] Arm inotify only in server mode

Re: [Openvpn-devel] [PATCH applied] Fix wrong configure.ac parsing of --enable-async-push

Re: [Openvpn-devel] [PATCH] Correctly state the default dhcp server address in man page

Re: [Openvpn-devel] [PATCH] Fix wrong configure.ac parsing of --enable-async-push

[Openvpn-devel] [PATCH] Fix wrong configure.ac parsing of --enable-async-push

Re: [Openvpn-devel] fuzz testing by google ?

Re: [Openvpn-devel] FreeBSD port versions (was: [PATCH applied] Re: Repair topology subnet on FreeBSD 11)

[Openvpn-devel] [PATCH applied] Re: Correctly state the default dhcp server address in man page

Re: [Openvpn-devel] [PATCH] Correctly state the default dhcp server address in man page

Re: [Openvpn-devel] [PATCH v3] Refactor setting close-on-exec for socket FDs

[Openvpn-devel] [PATCH v3] Refactor setting close-on-exec for socket FDs

[Openvpn-devel] Topics for the upcoming (Wednesday, 7th Dec 2016) community meeting

Re: [Openvpn-devel] [PATCH] Refactor setting close-on-exec for socket FDs

15 matches

Site Navigation

Mail list logo

Footer information