Re: Inconsistency in flags sent to GetSecrets() for VPN connections



On Wed, 2020-08-26 at 09:03 +0300, Ionuț Leonte via networkmanager-list 
wrote:
Hello,

I have the following code:

    import gi
    gi.require_version('NM', '1.0')
    from gi.repository import GLib, Gio, NM


    def handle_method_call(
        connection, sender, object_path, interface_name,
        method_name, params, invocation
    ):
        if interface_name ==
'org.freedesktop.NetworkManager.SecretAgent':
            if method_name == 'GetSecrets':
                conn, path, sett, hints, flags = params.unpack()
                print(f'GetSecrets():')
                print(f'  path = {path}')
                print(f'  sett = {sett}')
                print(f'  hints = {hints}')
                print(f'  flags = {flags}')

                invocation.return_value(
                    GLib.Variant.new_tuple(GLib.Variant('a{sa{sv}}',
{}))
                )
                return

            invocation.return_value(GLib.Variant('()', ()))


    xml_path = 'org.freedesktop.NetworkManager.SecretAgent.xml'  #
from [2]

    xml = open(xml_path, 'r').read()
    node = Gio.DBusNodeInfo.new_for_xml(xml)

    print(f'Getting DBus proxy for org.freedesktop.NetworkManager')
    proxy = Gio.DBusProxy.new_for_bus_sync(
        Gio.BusType.SYSTEM,
        Gio.DBusProxyFlags.NONE,
        None,
        "org.freedesktop.NetworkManager",
        "/org/freedesktop/NetworkManager/AgentManager",
        "org.freedesktop.NetworkManager.AgentManager",
        None,
    )

    print(f'Registering SecretAgent interface')
    proxy.get_connection().register_object(
        "/org/freedesktop/NetworkManager/SecretAgent",
        node.interfaces[0],
        handle_method_call,
        None, None
    )

    print(f'Registering SecretAgent object')
    proxy.call_sync(
        "Register",
        GLib.Variant.new_tuple(GLib.Variant.new_string('dev.ileonte.V
PNSSO')),
        Gio.DBusCallFlags.NO_AUTO_START,
        -1,
        None)

    loop = GLib.MainLoop()
    loop.run()

It registers as a SecretAgent and prints the parameters that
NetworkManager
sends to its GetSecret() method.

With KDE - tested on Gentoo (NM version 1.26.0) and Kubuntu 20.04 (NM
version
1.22.10) - I see the following (correct?) behavior:
  - when I go to System Settings > Connections and click on a VPN
connection
    (to see the settings of the connection) my GetSecrets() function
gets
    called once with flags=4 (ie. USER_REQUESTED - see [1])
  - when I try to activate a VPN connection (via nmcli OR from the
connections
    page in System Settings OR via the Plasma NetworkManager applet)
my
    function gets called twice - once with flags=4 then immediately
after
    with flags=5 (USER_REQUESTED | ALLOW_INTERACTION)

With GNOME - tested on Fedora 32 (NM version 1.22.14) and Ubuntu
20.04 (NM
version 1.22.10) - I see the following (incorrect?)
behavior:
  - when I go to Settings > Network and edit a VPN connection my
function
    gets called once with flags=4 (same as the KDE case)
  - when I activate a VPN connection via nmcli or from Settings >
Network my
    function gets called twice - once with flags=4 and once with
flags=5
    immediately after
  - (!!) when I activate a VPN connection via the GNOME
NetworkManager applet
    however my function only gets called once with flags=4. After
that the
    default authentication dialog pops up and my function never gets
called
    again. Furthermore, when testing with an OpenConnect VPN, I can
see that
    nm-openconnect-auth-dialog gets run with the `-i` (interactive)
parameter
    even though my function gets called without ALLOW_INTERACTION set
in flags

I have tested with two types of VPN connection (OpenConnect and
OpenVPN) and
I have seen this in both cases.

Is this intended behavior? Seems to me like the GNOME applet is maybe
missing
some fix that was applied to the Settings > Network page in GNOME.

PS: On an older distribution (Ubuntu 18.04 with NM version 1.10.0) my
function
always gets called with flags=4 so it looks to me like support for
ALLOW_INTERACTION was introduced only to some of the components.


[1] 
https://lazka.github.io/pgi-docs/#NM-1.0/flags.html#NM.SecretAgentGetSecretsFlags
[2] 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/master/introspection/org.freedesktop.NetworkManager.SecretAgent.xml

hi,

I don't know.

Something does sound wrong here.


I would think that NetworkManager shouldn't behave differently between
nmcli, nm-applet or plasma-nm/KDE. In the end, they are all D-Bus
clients, it's not clear why that would result in different behavior.
Also, for the most part, the distros should ship something close to
upstream, so it's not clear why you would see a difference on Fedora
32.

I think to really understand you should look at level=TRACE logs of
NetworkManager. It should tell you why/which secret-agents are prompted
and why. I guess, you'd also have to check the sources. Sorry, that it
isn't that straight forward, but new secret-agents only get implemented
once per decade, and they are debugged only rarely.

Looking at logs seems most important. See 
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28
 for hints about logging.


best,
Thomas

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]