Update to OpenVPN 2.1-RC9

Grrr ... Someone decided to implement more security by changing the way the "--up" parameter works ...

That's the first time, I can imagine, that OpenVPN introduced changes, that are incompatible to a previous version.

The Scenario

Normally I'm running openvpn in a bridge-mode setup. Even on the clientside (on linux) I have a bridgedevice, that is bound to a static IP and the tap-device created by openvpn is than added to the bridge.

My configfiles have(had) the following lines in it:

dev-type tap
dev tohome
up "brctl addif homenet tohome; ifconfig tohome up; echo"

This means:

  • Create an Ethernet(TAP-)Device called "tohome"
  • Put it into the bridge called "homenet"
  • set the Interface "tohome" up
  • the "echo" is a tweak to accept the parameters, that are delivered from openvpn

What happened

OpenVPN before 2.1RC9 executed the complete string with an system()-call, that made it possible, to execute it like a shell-oneliner.

Now the behaviour changed to an incompatible execve() call, that tries to execute the file thats described in the string and can only pass the parameters from OpenVPN.

So aside from the effect, that they introduced "script-security-levels" (which is a compatible change, because it doesn't change the semantics of an existing feature) I'm quite screwed, to write multiple wrapper-scripts.

Because of my Xen-Setup I have different bridges and different connect scenarios, I need for every bridge I'm connecting to another wrapper script, because I can't simply pass the string by parameter. Also, if I want to do some minor changes to one OpenVPN-instance in the up-script (who knows?) I have to create a wrapper script for every OVPN-instance.

This step was necessary for some raceconditions concerning persistent tuns and renegotioations/restarting.

What I want to stress:

It's not a good practice, to change semantics of how things work. Maybe it's good to change the default of how things work, but then one needs to have a "--yes-I-am-idiot-but-gimme-old-behavior=now" -switch .

There is a wya, to "reduce" the script-security-level to old behaviour (accepting every script) "--script-security=3" ... and also when the format of the status-file was changed between the version 1 and 2 there has an switch been introduced, to select old behaviour.

For the current case I could even live with an option "--old-unsafe-legacy-up='xxxxx'" option to retain old behaviour. But simply killing the option to write semicolon-delimited simple shell commands is in my opinion not acceptable.


While I'm at it: there's a little minor problem with the options. The "--passtos"-Option seems to be "deactived" (or obsolete?) in recent versions. It is still mentioned in the manpage as well as the commandline-help.

Of course - it's an RC-version and not yet released. And I've yet to write a bug-report for that, yes.

Füge einen neuen Beitrag hinzu. Titel:

Discussion is open