Bug 1060460

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Different VPN services use different names for a user name:
- openvpn     -> "username"
- vpnc        -> "Xauth username"
- pptp        -> "user"
- openconnect -> "username"
- openswan    -> "leftxauthusername"

These names are configured in hash table - vpn.data property.

The vpn.user-name property should be left empty in most cases.

If you want modify the username, change "username" in vpn.data:
nmcli> set vpn.data username=my-new-name

Created attachment 889325 [details]
[PATCH] keyfile: don't put VPN 'user-name' property to vpn.data

The vpn.user-name property of NMSettingVPN is only used for passing the default username from NM to the VPN plugin, which is filled with the username of the agent that returned secrets for the request.  It shouldn't ever be read or written by the user session or by settings plugins.  If the user wishes to override the default username with a different one (eg, their VPN username is different than their Unix login) they set that manually in the VPN plugin's UI and the VPN uses custom data items for this.

So it's correct that no plugin should store vpn.user-name.

Patch looks good to me.

Patch looks good to me too

The commit has been pushed to upstream master:
050c30d keyfile: don't put VPN 'user-name' property to vpn.data on read (rh #1060460)

I went by the original reproducer, configured an openvpn connection via gnome plugin with username vhumpa, then ran "nmcli con modify id openvpn vpn.user-name franta" getting both "user-name" and "username" present:

[vpn]
service-type=org.freedesktop.NetworkManager.openvpn
user-name=franta
username=vhumpa
remote=somegateway.org
connection-type=password
password-flags=1

Now, is that *what* we want here considering the vpn.user-name property should not really be used?

(In reply to Vitezslav Humpa from comment #9)
> I went by the original reproducer, configured an openvpn connection via
> gnome plugin with username vhumpa, then ran "nmcli con modify id openvpn
> vpn.user-name franta" getting both "user-name" and "username" present:
> 
> [vpn]
> service-type=org.freedesktop.NetworkManager.openvpn
> user-name=franta
> username=vhumpa
> remote=somegateway.org
> connection-type=password
> password-flags=1
> 
> Now, is that *what* we want here considering the vpn.user-name property
> should not really be used?

This is correct. Vpn.user-name option produces user-name line in keyfile. This vpn.user-name is used very rarely and should stay empty most of the times. The change is in the user-name option not being propagated to vpn.data hash table as it was before. Just username is. 
So the correct way of setting username for your vpn should be via set vpn.data username=franta if you want to pass it to openvpn. There is no incorrect user-name option in vpn.data and vpn.user-name is very likely ignored.

As Vladimir correctly described, "vpn.user-name" property is not interesting and is not used to configure the user name. User name should be configured in vpn.data and the actual property name differs according to VPN types - see comment #3.

What this bug changes is that now vpn.user-name (if set) won't overwrite usernames properties in vpn.data. (As you can see in your keyfile, "username" is still vhumpa).

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0311.html