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

On Thu, Aug 27, 2020 at 10:51:26PM +0300, Ionuț Leonte wrote:

I went back and tested again with TRACE logging enabled, here are the results:

- GNOME on Fedora 32 (NM 1.22.14):
  * activating via applet:
  * activating via settings page:
  * activating via nmcli:
- KDE on my Gentoo desktop (NM 1.26.0):
  * activating via applet:

In all cases EXCEPT the GNOME applet case SecretAgents are queried in reverse
registration order:


In the GNOME applet case the order of the checks is reversed. The PID of the
process that sent the connection activation request does match with the PID
of gnome-shell. HOWEVER, in the KDE applet case the PID of the process that
activates the request is that of plasmashell but the order in which the agents
are queried is the 'correct' one (reverse registration order).

It seems the opposite to me:

 - with GNOME Shell, the agent and the process performing the
   activation/deactivation are the same (176175):

    NetworkManager[164282]: <trace> [1598619148.2117] secret-agent[71d46805cd8d105d]: constructed: 
:1.30113/org.gnome.Shell.NetworkAgent/1000, owner="user" (unix-process[pid=176175, uid=1000, 
start=123260954]), unique-name=":1.28604", capabilities=vpn-hints

    $ ps -q 176175
    176175  ?  0:12 /usr/bin/gnome-shell

    NetworkManager[164282]: <info>  [1598619276.5219] audit: op="device-disconnect" interface="enp8s0" 
ifindex=5 pid=176175 uid=1000 result="success"

 - with KDE plasma they are different. The agent is kded5, while operations are performed by plasmashell

    NetworkManager[164282]: <trace> [1598618060.2848] secret-agent[1563bf6e47b8e3f7]: constructed: 
:1.29823/org.kde.plasma.networkmanagement/1000, owner="user" (unix-process[pid=174878, uid=1000, 
start=123188141], unique-name=":1.28604", capabilities=none

    $ ps -q 174878
    174878  ?  0:01 kded5 [kdeinit5]

    NetworkManager[164282]: <info>  [1598618534.6393] audit: op="connection-activate" 
uuid="83037490-1d17-4986-a397-01f1db3a7fc2" name="nat" pid=174931 uid=1000 result="success"

    $ ps -q 174931
    174931  ?  0:57 /usr/bin/plasmashell

Also in the GNOME applet case the log for the GetSectet() calls with flags=5
is weird - NM says:


but that can't possibly be right because all I did was close the auth-dialog
window as soon as it popped up so I'm not sure what 'secrets' were returned
exactly. This is probably why my own GetSecrets() function is never called with
flags=5 in this case - as far as NM is concerned the first secret agent it
queried told it that it had the secrets for the connection even though it
really didn't.

That is probably a bug in the GNOME dialog.

Is there any config option to disable the prefer-pid-of-the-activating-process
logic in NM? This seems like a really arbitrary thing to have in there.

This behavior is what makes most sense to me. If the user activates a
connection through an application X, then it is better to ask the
secrets through the same application X the user is currently working
on instead of spawning a dialog from an unrelated application Y.

This behavior is useful for example when users activate connections in
the terminal through "nmcli --ask connection up" or "nmtui", to avoid
spawning graphical dialogs and ask secrets in the same application.


Attachment: signature.asc
Description: PGP signature

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