Don't delete them if we don't have permission for them, since
we may get permission for them later via Update. But to listen
for Update we need the connection around.
When the connection becomes invisible to a user (ie, the permissions
of the connection no longer allow that user to view the connection)
then we have to hid the connection from clients. But we can't
just dispose of it, because visibility changes are signaled with
Update signals on the connection itself, and thus we need to keep
the connection around just in case it becomes visible to the user
again. But if it's invisible, make sure we clear out the settings
since they may have changed.
We can't unregister the object with the bus during the remove signal,
because dbus-glib doesn't send the signal out over the bus until late
in the signal emission process, after we've unregisterd the object.
Thus the signal doesn't go out. Fix that.
Make sure to use modify.system if the Update request changes the
visibility of the connection, since that update request would
affect more users than just the caller.
Can't just check whether we have existing system secrets, because
that doesn't catch the case for a completely new connection where
there may not be any secrets yet, but any that we do get should
be system-owned.
When a connection is visible only to one user, check 'own' instead
of 'system', allowing 'own' to be less restrictive since the change
won't affect any other users.
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.
