Timestamps are no longer written to the connection file itself, but
are kept in a lookaside file in /var to allow for read-only or
stateless /etc and to ease system administration and deployment.
NM updates timestamp for active connections every 5 min. We don't
want to touch files in /etc due to this. This commit solves that
by not updating timestamp in the connection's property. Rather it
updates the timestamp internally. All timestamps are also kept track
of in /var/lib/NetworkManager/timestamps file.
When settings are requested via D-Bus GetSettings(), the proper
timestamp is put in the connection setting before returning.
Some adjustments need to be made to read and write secret flags, and
to ensure that connections that don't have system-owned secrets are
still parsed as expected. testcases for 802.1x connections to come
shortly.
Clients need to do their own logging using glib or whatever; these
macros while somewhat helpful were not flexible and are not a
substitute for actual logging in the client. g_warning, g_message,
and g_error are more suitable anyway.
It's always used with a GByteArray anyway, as are most
functions in nm-utils.h. Even better, we can skip the
memcpy since it turns out to be pointless.
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.
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 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.
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.
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.
If the agent returns system-owned secrets, like when activating a new
connection which was created with no secrets, make sure the agent is
authorized to modify network settings before saving or using the
new secrets.
