This policy will allow users to modify their personal connections (ie
maybe VPN connections, etc) distinctly from system-wide connections that
affect more than just their user. It makes sense to be more lenient when
making changes to settings that don't affect other users.
Meaning stays the same, but this will allow us to differentiate
in the future between personal connections (ie, just visible to
one user) and system connections (visible to more than one user).
We don't want these secrets in the NMSettingsConnection's internal
secrets cache since they shoulnd't ever be read off-disk, and they
should be discarded immedaitely after use. Similarly, we want to
remove any of these secrets that do come through from a secrets
request that doesn't allow user-interaction, since not-saved secrets
aren't allowed there.
We're already connected; shouldn't need secrets again but
if we do, we'll ask for them again. Fixes an issue where
reconnect would use an old one-time-password.
We need to iterate through each item in the VPN's 'secrets' property
and mark it as not required, instead of just marking the 'secrets'
property itself as not required. Yeah, VPN secrets are a bit
annoying.
The caller has already taken care of making sure that the
agent is privileged enough to have secrets, so send them along
if the caller gave them to us.
Since ifcfg-rh uses the connection's ID as the filename by default,
we could run into a situation where two connections with the same
ID are visible to different users. We don't want one connection
overwriting the other in that case, so we need to pick a new name
for the one we're about to write.
When getting status of NetworkManager via 'nmcli nm ...' and NetworkManager
is not running, do not call its D-Bus methods. It prevents NM to be implicitly
executed when configured as D-Bus activated service.
Since keyfile uses the connection's ID as the filename by default,
we could run into a situation where two connections with the same
ID are visible to different users. We don't want one connection
overwriting the other in that case, so we need to pick a new name
for one of them. Append the connection's UUID to the end to
minimize the risk of further conflicts for that name.
Because most of the time they will. They need special handling all
around anyway because only the VPN plugin itself knows whether the
connection needs secrets.
The old function took a string value, which wasn't really correct as
the property type is a GHashTable of string:string. For whatever
reason this is how nm-applet passed VPN secrets back to NM in the return
from the GetSecrets() D-Bus call. This was probably easier or
something but it was a special case that's magic and quite unclear.
Since we use nm_connection_update_secrets() more these days, and we
depend on the GValue types we pass into it matching the property
types of the setting property the secret is for, we need to fix that
up for VPN connections. But keep the old code for backwards
compatibility.
In the future secret agents should pass back VPN secrets in the same
form as the VPN setting specifies them for the "secrets" property:
a GHashTable of string:string. But the old mechanism of just dumping
the key/value pairs into the returned VPN hash as string:string will
still work.
Do the check for system-owned secrets once, before kicking off the
request, instead of each time we ask an agent. As a bonus, this
change ensures priv->secrets doesn't store anything except
system-owned secrets too, simplifying some checks later on.
Not all connections will require every secret, and sometimes we
can't automatically figure out whether we need the secret. For
vpnc sometimes the group password isn't used, and sometimes PPP
providers require a username but don't want a password, etc.
Just because the key isn't saved (ie, the user hasn't entered it yet,
or the user want to type it in every time) doesn't mean the setting isn't
WEP, so recognize it as WEP if DEFAULTKEY or SECURITYMODE is set.
If we can authenticate the agent for 'modify' permission, then send
any existing system secrets to it as the user has permission to change
those secrets. This means the agent doesn't have to call GetSecrets()
itself, which means simpler code on the agent side for a slight LoC
hit in NM itself.
This also moves the permissions checking into the NMAgentManager to
check each agent, which is sub-optimal since now the agent manager
has to do PolicyKit stuff, but hey that's life. Agents need secrets,
and we do need to authenticate every agent before we send secrets to
them, and the NMSettingsConnection doesn't know about individual
agents at all.
