override-username not applied to consecutively called plugins

[sp-andwei]

Hi,

Probably not exactly a bug, but at least for me undesired behavior: I was playing with the soon-to-be-introduced --override-username option, setting it from within a plugin using a temporary client_config_file at the OPENVPN_PLUGIN_CLIENT_CONNECT step.

What I noticed is that consecutively called plugins are not called with the updated username, but still get the "original" username, even when registered for the OPENVPN_PLUGIN_CLIENT_CONNECT_V2 step and being registered after the username-overriding plugin.

In the context of the plugin, which implements external webauth via OIDC, the original username is basically an empty string and thereby not helpful for that "other" plugin that just records (dis-)connection events.

To Reproduce Register two plugins and have the first pass the override-username option using a client_config_file. The second plugin will receive the original username in its envp-array

Expected behavior The second plugin receives the updated username on its OPENVPN_PLUGIN_CLIENT_CONNECT_V2 call.

Version information

• OS: Ubuntu 24.04
• OpenVPN version: v2.7_alpha2/master

Additional Context I managed get the desired behavior by having openvpn call the override_locked_username function earlier, within multi_client_connect_post:

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index a760e071..1cda7188 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1679,6 +1679,10 @@ multi_client_connect_post(struct multi_context *m,
          */
         multi_select_virtual_addr(m, mi);
         multi_set_virtual_addr_env(mi);
+        if (mi->context.options.override_username)
+        {
+            override_locked_username(mi);
+        }
     }
 }

It does work for my scenario, however, I'm not quite sure if I'm missing some important problem with that approach and would be happy about input in that regard.