Password is deleted from secret service keyring before attempting to connect

[m-col]

Hello

I can successfully connect to my work's VPN but I have to enter my password every time. I have the setting enabled for it to be stored for only this user, but entering the password either in the configuration or the password dialog does not result in it being stored. Storing works fine when I use this:

printf "<password>" | secret-tool store --label="myvpn" connection-uuid 065e0605ac08-48be-a0ea-db33a7e1542

Then when I try to connect, nm-l2tp deletes that entry from my keyring.

Confusingly, if I use gnome-keyring then nm-l2tp will always prompt after deleting the password, whereas if I use keepassxc's secret service then it will succeed to connect without the prompt even if I let it delete the password (keepassxc will ask the user to confirm deletions).

This only happens when I configure it to store the password only for this user; everything seems to be fine when the password is stored for all users.

Is this intentional, and I've misunderstood something? Or is the password meant to be stored in the keyring when entered in the configuration and then withdrawn from then on when connecting?

[dkosovic]

That sounds like a bug.

nm-l2tp's auth dialog box definitely doesn't delete anything from the secret service:

• https://github.com/nm-l2tp/NetworkManager-l2tp/blob/master/auth-dialog/main.c

It does use the nm_vpn_service_plugin_get_secret_flags() function in NetworkManager's libnm to determine if a password is required. Its only direct interaction with the keyring is for looking up the secret in keyring_lookup_secret() function :

• https://github.com/nm-l2tp/NetworkManager-l2tp/blob/master/auth-dialog/main.c#L41

Unless libsecret's secret_value_unref() has started to do more than change the reference count for the local variable and actually deleted the corresponding entry in the secret service, I can't see where in the nm-l2tp code it could be deleting it from the secret service. More info on secret_value_unref() :

• https://developer.gnome.org/libsecret/unstable/SecretValue.html#secret-value-unref`

I could try and reproduce it if I know which Linux distro, version of NetworkManager and version of NetworkManager-l2tp you are using? Perhaps also which desktop environment you are using?

[m-col]

I'm using Arch Linux with NetworkManager version 1.24.0-1 and NetworkManager-l2tp version 1.8.2-1, running in the Qtile window manager.

[dkosovic]

Rather than install Arch Linux, I just tested with a Fedora 31 VM I had handy. I used NetworkManager-l2tp version 1.8.2-1. I installed Qtile 0.13.0 and network-manager-applet package (for /usr/bin/nm-applet). Using nm-applet, I wasn't able to reproduce the store the password only for this user related issue. I was able to reconnect the VPN connection multiple times without the stored password getting deleted nor was there any password user confirmation. gnome-keyring-daemon appears to be running.

I stored the password only for this user using nm-connection-editor.

Sorry I'm not sure what the issue could be.

[dkosovic]

According to the Arch Linux NetworkManager wiki, for Store the password only for this user to work, the keyring needs to be unlocked. Not sure what that means.

• https://wiki.archlinux.org/index.php/NetworkManager#Using_GNOME_Keyring

[m-col]

Upon further inspection, when I monitor keepassxc's secret service, it looks like nm-l2tp is trying to save the password each time and keepassxc is asking for confirmation of the "deletion" which is actually due to it overwriting of the existing entry. This is apparent because the key entry persists in keepassxc, while an identical key entry appears in keepassxc's trash folder. The confirm-delete prompt doesn't happen on the first connection attempt because the key isn't saved to keepassxc when I enter it into nm-connection-editor (or nm-applet) and select Store the password only for this user.

I'm seeing completely different results monitoring gnome-keyring-daemon with seahorse; the password is never saved to the keyring unless I enter it manually using secret-tool, and then upon connecting the password is deleted completely from the keyring and there is always the prompt.

Given the inconsistent behaviours with the two secret services and the general lack of much standardisation in the way keyrings and key entries should be structured for these secret services, I'd probably just chalk it up to there being something weird with my specific dbus setup. I can get around it and stop the prompts by just storing the password "for all users", which is working well.