On 09/05/17 16:52, selva.n...@gmail.com wrote:
> From: Selva Nair <selva.n...@gmail.com>
>
> v2: Change the plugin open to use v3 API so that
> openvpn_secure_memzero() exported from OpenVPN can be used.
>
> Note: context is cast as (openvpn_plugin_handle_t *) for consistency
> with the current plugin header. If/when the header is fixed, change
> this cast as well.
>
> Signed-off-by: Selva Nair <selva.n...@gmail.com>
> ---
> src/plugins/auth-pam/auth-pam.c | 31 ++++++++++++++++++++++++++-----
> src/plugins/auth-pam/auth-pam.exports | 2 +-
> 2 files changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/src/plugins/auth-pam/auth-pam.c b/src/plugins/auth-pam/auth-pam.c
> index d3e2c89..f3566c7 100644
> --- a/src/plugins/auth-pam/auth-pam.c
> +++ b/src/plugins/auth-pam/auth-pam.c
> @@ -63,6 +63,9 @@
> #define RESPONSE_VERIFY_SUCCEEDED 12
> #define RESPONSE_VERIFY_FAILED 13
>
> +/* Pointers to functions exported from openvpn */
> +static plugin_secure_memzero_t plugin_secure_memzero = NULL;
> +
> /*
> * Plugin state, used by foreground
> */
> @@ -274,8 +277,10 @@ name_value_match(const char *query, const char *match)
> return strncasecmp(match, query, strlen(match)) == 0;
> }
>
> -OPENVPN_EXPORT openvpn_plugin_handle_t
> -openvpn_plugin_open_v1(unsigned int *type_mask, const char *argv[], const
> char *envp[])
> +OPENVPN_EXPORT int
> +openvpn_plugin_open_v3(const int v3structver,
> + struct openvpn_plugin_args_open_in const *args,
> + struct openvpn_plugin_args_open_return *ret)
> {
> pid_t pid;
> int fd[2];
> @@ -285,6 +290,16 @@ openvpn_plugin_open_v1(unsigned int *type_mask, const
> char *argv[], const char *
>
> const int base_parms = 2;
>
> + const char **argv = args->argv;
> + const char **envp = args->envp;
> +
> + /* Check API compatibility */
> + if (v3structver != OPENVPN_PLUGINv3_STRUCTVER)This generally looks good. Going to run some tests. But I think the if() line above needs a reconsideration. If the plug-in built and packaged separately and that build is not tied to OpenVPN itself, this can make this plug-in fail without any particular real reason if the OpenVPN binary gets updated independently. Even though not explicitly documented, we should never remove any information from the plug-in v3 structs, only append to and only append at the end of the existing structs. This should help ensure backwards compatibility. So if a plug-in is built against OPENVPN_PLUGINv3_STRUCTVER being 3, that plug-in binary should work out-of-the-box even if OpenVPN is updating to OPENVPN_PLUGINv3_STRUCTVER set to 4. The sample plug-ins do have a strict requirement (v3structver != OPENVPN_PLUGINv3_STRUCTVER) but that is more meant to be a kind of sanity check for us when testing the plug-ins during OpenVPN development. That tells is instantly if we've remembered to rebuild the sample plug-in. The plug-ins in src/plugins should use, which ensures forward compatibility against the OpenVPN binary: if (v3structver < OPENVPN_PLUGINv3_STRUCTVER) So if OpenVPN gets upgraded the plug-in will still work, new features exists but the plug-in isn't written to make use of them. If OpenVPN gets downgraded with a lesser plug-in API, it will complain as features are missing. In fact, if a plug-in only needs the feature-set of OPENVPN_PLUGINv3_STRUCTVER 2 or 1, it is possible replace the macro constant with the appropriate integer value. That can ensure the plug-in works regardless of which version of the openvpn-plugin.h it is built against. (And yes, I do realise we need more proper plug-in documentation) -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
