Nominating for blocker discussion based on https://fedoraproject.org/wiki/Basic_Release_Criteria#VPN_connections

I mean, this is arguably correct, isn't it? You're making a significant change to the entire system's network connection. If any unprivileged user can connect the system to an arbitrary VPN...that feels like a security problem.

We could consider not requiring users with admin privileges to re-authenticate to allow this, but I think it's correct not to allow unprivileged users to do it?

Well, that would be for sure considered as a "security enhancement", however, as this "new" behaviour is a really surprisinf change, it would be easily mismatched what "password" to type. And it is for sure incovenient.

Petr's initial bug report was to complain that connecting to OpenVPN now spawns two password dialogs, first for sudo password, second for VPN password. It used to be just the second one.

I asked him to test what happens with unprivileged users, whether it prevents them from connecting (to a system-wide VPN profile). It seems it does. I don't know what the behavior was in Fedora 43 in this case, that needs to be tested.

I understand that, but I'm saying there's a legit reason to require both kinds of authorization. Just because you know the password for a VPN (i.e. you're authorized by the VPN provider to access the VPN) doesn't mean you are authorized by the admin of the local system to connect *it* to the VPN.

As I said, I do think there'd be an argument for allowing admin users to do this without requiring them to re-authenticate, we do that for various other things. It's a judgment call. It'd be good to pinpoint the actual change here (it'll be to some polkit policy or other) for more context, and ask the author what their intent was...

Being able to join the VPN from the GDM login screen will break if we only allow with admin users, or requiring sudo.  (This is something we rely on for our internal Fedora build because people often forget their passwords and they need to be on the VPN for a new one to work)

If you want to require admin authentication to use a VPN, better do so when initially configuring the VPN, not every single time you connect to it....

In any case, it's a substantial change from current behaviour, and as such, should at least be intentional (is it?) and probably have gone through the appropriate process. At this point in time it's rather a regression to be fixed.

This new behavior is the effect of a change [1] done to fix a security issue, where non-admin users can create connection profiles that refer to other users' keys.

Before this change, any user with local access could create and modify system-wide connection profiles (i.e. those with an empty `connection.permissions` property). After the change, only administrators can do that. Non-admin users can only create and modify "private" connections (with `connection.permissions = user:$username`), and NetworkManager will check at activation time that the user can access any certificate/key file paths included in those connections.

Unfortunately, providing a password for a system-wide connection also requires the same polkit permission (`org.freedesktop.NetworkManager.settings.modify.system`) required for adding/modifying it, because in some cases the password will be stored in the profile as the result of a successful authentication.

The possible solutions to this are:

 1. Leave things as they are now in Rawhide, and from now on require that non-admin users connect to VPNs using non-system connection profiles. This might require conversion of existing profiles and other adjustments to the tooling, GUIs, etc. This will require also a Fedora Change Proposal.

 2. Try to fix the problem of the double password request for VPNs without undoing the polkit permissions change. Specifically, if the VPN is requesting a OTP password (i.e. a password that will not be stored on disk), it should not be necessary to require the "modify.system" permission. For other cases, like when the password is stored, the behavior will remain similar to solution 1, and users will need admin privileges to add/modify/activate "system" connections.

 3. Revert the permission change and re-introduce the security issue.

We discussed this with Inigo and we wanted to try option 2. However it is not clear if fixing the behavior only for 2FA VPNs is enough, or there are other issues.

[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/0b75d905e59999539ab1e92a92646b634c221215

-4 in https://pagure.io/fedora-qa/blocker-review/issue/2026 , marking rejected as a blocker. Proposing as an FE as it *is* annoying and would be good to land any safe improvements during freeze.

Beniamino, is it not possible to use the setup where an action is allowed for admin users *without requiring them to re-authenticate*?

If option 2 doesn't work, then you should surely be able to suppress the authentication prompt for admin users by writing a polkit JavaScript rule to check for wheel group.

> If option 2 doesn't work, then you should surely be able to suppress the authentication prompt for admin users by writing a polkit JavaScript rule to check for wheel group.

You are right, we actually have a mechanism for that but it's currently disabled on Fedora 44. That is, we removed `-Dmodify_system=true` and we didn't enable this:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/d8f143f60146e847c673acceb1102417c3cd85a2

I will investigate if we can implement option 2, otherwise we need to enable the polkit rule.

AGREED AcceptedBetaFreezeException

Discussed at the 2026-02-16 (blocker / freeze exception) review meeting:

This is accepted as it's a pretty annoying experience for VPN users, and it would clearly be better to ship with it fixed if safely possible.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-02-16/f44-blocker-review.2026-02-16-17.00.txt

*** Bug 2432442 has been marked as a duplicate of this bug. ***

I wonder if there is an option to have local network (OpenVPN) profiles?

And also, while Jonathan in comment #6 mentions login from GDM, this is also not cool, because such connection requires to have specified `username`. This is IMHO not good idea for global profile.

Lastly, it is quite common to enable system wide network connection just by plugging cable into computer. From that POV, not requiring admin password for enabling VPN is fine.

IOW I'd say there are gaps and this would deserve some design work.

(In reply to Vít Ondruch from comment #15)
> I wonder if there is an option to have local network (OpenVPN) profiles?

s/local/user/

Adding a regression keyword for f44:
The following user script has stopped working:

echo "vpnpassword" | nmcli con up "Brno (BRQ)" --ask

This affects connections restricted to a single user.
If current security policies now prevent network changes this way, we should consider a redesign.

FEDORA-2026-e7dadc931f (NetworkManager-1.56.0-1.fc45) has been submitted as an update to Fedora 45.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-e7dadc931f

I have submitted an update for F44: https://bodhi.fedoraproject.org/updates/FEDORA-2026-0060197eeb which introduces the following changes:

 - Local admin users now get the "modify.system" permission without further authentication, which allows them to modify system connections and to enter persistent secrets.

 - The activation of a system connection that only requires ephemeral secrets (like 2FA tokens) doesn't require the "modify.system" permission, as it doesn't change the profile on disk.

It should solve all the issues reported in this bz, please try and let me know.

FEDORA-2026-0060197eeb (NetworkManager-1.56.0-1.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-0060197eeb

FEDORA-2026-0060197eeb has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-0060197eeb`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-0060197eeb

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

sudo dnf upgrade --advisory=FEDORA-2026-0060197eeb --enablerepo=\*

version
NetworkManager-1.56.0-1.fc44.x86_64

sudo is NOT required for user's vpn

https://bodhi.fedoraproject.org/updates/FEDORA-2026-0060197eeb > karma++
---
thanks!!!

Thanks for testing, Petr, marking as verified.