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
signature.asc
Description: PGP signature
_______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
