On Thu, Mar 10, 2022 at 12:18 PM Gert Doering <g...@greenie.muc.de> wrote:
> The actual plugin calls are no longer done with the "do them all" > function plugin_call() (or plugin_call_ssl()) but plugin.c/plugin.h > is changed to expose the "call one" function plugin_call_item(), and > verify_user_pass_plugin() calls this for each loaded plugin, > keeping track of "overall" state. > > key_state_test_plugin_auth() is introduced to do the > "key_state_test_auth_control_file()" test for all plugins, and > return "FAIL if one fails, PENDING if one is pending, SUCCESS > if one was pending and succeeded now". > Since the handling is changing from "do them all' to "call one and FAIL on first failure," may I suggest a feature enhancement? Linux PAM uses auth plugins too, and each plugin has a control flag of required, requisite, sufficient, or optional. To date, OpenVPN handles auth plugins as if each were required (proceed with next regardless of failure), but with this patch, that will change to requisite (fail immediately on first failure). What if, as part of the openvpn plugin config, we could set the behavior explicitly, much like PAM allows? For reference: http://linux-pam.org/Linux-PAM-html/sag-configuration-file.html This would allow OpenVPN to handle alternate authentication paths, such as: > plugin sufficient /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login > plugin requisite /usr/share/openvpn/plugin/lib/openvpn-auth-ldap.so login > plugin required /usr/share/openvpn/plugin/lib/openvpn-auth-duo.so login > skey=abc ... > This setup would succeed immediately if the user successfully authenticates with a local account; otherwise it would require LDAP and Duo MFA, but would not query Duo if LDAP failed. Such control would be constrained by the deferral mechanism, as the deferred result cannot be immediately evaluated, so I think it makes sense that all deferred plugins are assumed to be required and must follow any plugins marked as requisite/sufficient. Alternatively, if a deferred plugin is marked as sufficient or requisite, it could hold further processing until the deferred result is returned, but that negates much of the asynchronous advantage that deferral gives us. So that config files don't need updating between versions, I think it's also wise to use a default flag if one is not specified. I would suggest non-deferred results default to requisite and deferred to required. Or if you want strict compatibility with existing behavior, you could default all to required. On that note, regarding serial vs. parallel launching of multiple deferred plugins, unless PAM-like control is implemented and plugins are allowed to be sufficient or requisite, I vote for launching them all in parallel and returning FAIL if any one fails. Thanks, -- Pete
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
