On Thu, Aug 27, 2020 at 10:51:26PM +0300, Ionuț Leonte wrote:
Hello, 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: https://pastebin.com/raw/ubLUSusH * activating via settings page: https://pastebin.com/raw/jaR4EtuE * activating via nmcli: https://pastebin.com/raw/jfJuq2zW - KDE on my Gentoo desktop (NM 1.26.0): * activating via applet: https://pastebin.com/raw/gsrtaiy4 In all cases EXCEPT the GNOME applet case SecretAgents are queried in reverse registration order: [nmcli]->script->org.gnome.Shell.NetworkAgen/org.kde.plasma.networkmanagement 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. Beniamino
Attachment:
signature.asc
Description: PGP signature