[openSUSE] ProtonVPN asks for root password several times before every connection

[Dyrimon]

OS: openSUSE Tumbleweed ProtonVPN version: ProtonVPN CLI v3.7.2 (protonvpn-nm-lib v3.3.2; proton-client v0.5.1) Desktop: KDE Plasma 5

Before starting every connection (whether by cli or gui) ProtonVPN asks for root password, and that is 5-6 times! I have to enter sudo password for NetworkManager, pvpn-killswitch, pvpn-ipv6leak-protection, the final server that it connects to and couple more times for NetworkManager. The following dialog box shows up every time I switch or start a new connection.

[calexandru2018]

Hey @Dyrimon

First to set the correct expectations, we currently don't support openSUSE. Regardless, this issue seems to be mostly due to polkit rules, that's why you're being prompted. You have to manually tweak them (although I don't know why since most distros are already tweaked and generally have no issues)

[Dyrimon]

I'm aware of not supporting openSUSE, and this was installed from a community repository. The client works fine as expected. But polkit is continuously asking me password. I'm assuming this is related to kwallet but I don't know how to make it automatic. This might be related to https://github.com/ProtonVPN/linux-app/issues/13#issue-927727591

[calexandru2018]

Your is a different issue. Check this: https://github.com/ProtonVPN/linux-cli/issues/4#issuecomment-856004316

[Dyrimon]

I also tried using pam_kwallet to automatically unlocking kwallet following the article from archwiki

[Dyrimon]

Your is a different issue. Check this: #4 (comment)

I don't know how this relates to my issue. I've no issues with ipv6leaks and so have no idea what rules to change in polkit

[calexandru2018]

@Dyrimon i think you need to read the archwiki properly. It is stated that:

kwallet-pam is not compatible with GnuPG keys, the KDE Wallet must use the standard blowfish encryption.

The wallet cannot be unlocked when using autologin. <- reason why you might be prompted
The wallet cannot be unlocked when using a fingerprint reader to login . <- reason why you might be prompted
The wallet must be named kdewallet (default name). It does not unlock any other wallet(s). . <- reason why you might be prompted
If using KDE, one may want to disable Close when last application stops using it in KDE Wallet settings to prevent the wallet from being closed after each usage (WiFi-passphrase unlock, etc.). . <- possible reason
It may be needed to remove the default created wallet first, thus removing all stored entries. <- possible solution
If the kwallet Migration Assistant asks for a password after every login, rename or delete the ~/.kde4/share/apps/kwallet folder.

edit:

this relates to my issue. I've no issues with ipv6leaks and so have no idea what rules to change in polkit

If you look at the screenshot you provided me, it's due to polkit that you're getting that prompt (and possible kde wallet configuration).

[Dyrimon]

Yes, but none of the limitations of pam is present in my issue. I do not autologin, nor a fingerprint scanner, wallet name is kdewallet and thats the only one. Close when last application... is already disabled. I tried removing the default wallet and creating another naming kdewallet but no use. the wallet folder doesn't exist in ~/.kde4/share/apps/

[Dyrimon]

here is my /etc/pam.d/sddm config

#%PAM-1.0
auth     include        common-auth
auth     optional       pam_kwallet5.so
account  include        common-account
password include        common-password
session  required       pam_loginuid.so
session  include        common-session
session  optional       pam_kwallet5.so auto_start
session  optional       pam_keyinit.so revoke force

[Dyrimon]

@calexandru2018 I've solved this by taking a leaf out of DasCapschen's book and just allowed everything related to org.freedesktop.NetworkManager unrestricted access in /etc/polkit-1/rules.d/90-default-privs.rules:

'org.freedesktop.NetworkManager.checkpoint-rollback':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.enable-disable-connectivity-check':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.enable-disable-network':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.enable-disable-statistics':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.enable-disable-wifi':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.enable-disable-wimax':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.enable-disable-wwan':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.network-control':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.reload':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.settings.modify.global-dns':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.settings.modify.hostname':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.settings.modify.own':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.settings.modify.system':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.sleep-wake':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.wifi.scan':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.wifi.share.open':
			[ 'yes', 'yes', 'yes' ],
		'org.freedesktop.NetworkManager.wifi.share.protected':
			[ 'yes', 'yes', 'yes' ],

I don't know if this will severely weaken my system or not, but frankly I don't care. Either it's polkit's fault or pvpn's fault but I'm too tired to bother with this any more.

[calexandru2018]

Hey @Dyrimon

That severely weakens your system. I'll leave you the output of my configs so that you can check it out: cat /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy output can be found here

Edit: basically what matters there is that your defaults match my defaults for all those actions. (don't mind the description in all those languages)

[BenD780x9]

I have this problem too in my Fedora 34

[calexandru2018]

@BenD780x9 refer to the post I mentioned above please.

[Dyrimon]

Hey @Dyrimon

That severely weakens your system. I'll leave you the output of my configs so that you can check it out: cat /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy output can be found here

Edit: basically what matters there is that your defaults match my defaults for all those actions. (don't mind the description in all those languages)

Unfortunately your solution doesn't work for me. I've to go back to the "open door" approach. Problem is after every polkit update the rules are reverting back to the default one

[absolutez3]

@calexandru2018 on Fedora 34 kill switch doesn't seem to work on my laptop but does work on my desktop.

dummy is installed

kwallet is blowfish

for testing purposes I allowed all actions from org.freedesktop.NetworkManager.* which was reflected on 'nmcli general permissions'

Your /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy is the exact same as mine

[absolutez3]

protonvpn-dbus-wrapper.log protonvpn.log protonvpn-cli.log protonvpn-daemon.log @calexandru2018 logs from ~/.cache/protonvpn/logs

[mrcbax]

The official client should be forking the community client (which works perfectly and bypasses NetworkManager). This NetworkManager integration is hot trash.

Observing the same issues on ArchLinux. One of the "supported" linux options.

The dependency tree is too large:

• systemd
• polkit
• networkmanager
• nm-applet

There are many linux distros that will not have these items installed. And some that don't support them at all. Not to mention the whole anti-monolithic (anti-systemd) group of distros.

It feels like Windows/MacOS/Android developers who are used to a homogeneous environment are programming this application.

[Dyrimon]

There are many linux distros that will not have these items installed. And some that don't support them at all. Not to mention the whole anti-monolithic (anti-systemd) group of distros.

It feels like Windows/MacOS/Android developers who are used to a homogeneous environment are programming this application.

i agree, I think a properly packaged flatpak will solve this dependency problem and give broader access to "unofficial distributions".