When a connection changes on-disk, the in-memory copy of it may contain
transient secrets (agent-owned or not saved) that dont' get written out
to disk. When comparing the on-disk copy to the in-memory copy make sure
transient secrets are ignored so that we don't re-read the on-disk copy
needlessly.
It turns out we need a way to ignore transient (agent-owned or unsaved)
secrets during connection comparison. For example, if the user is
connecting to a network where the password is not saved, other
changes could trigger a writeout of that connection to disk when
connecting, which would the connection back in due to inotify, and the
re-read connection would then no longer be recognized as the same as
the in-memory connection due to the transient secret which obviously
wasn't read in from disk.
Adding these compare flags allows the code to not bother writing the
connection out to disk when the only difference between the on-disk
and in-memory connections are secrets that shouldn't get written to
disk anyway.
The FIXME is correct; comparing the whole connection is just dumb now
since all connections are owned by NM, so we can simply compare pointers
to figure out of the incoming activation request is using the same
connection as the current activation request. Plus, this comparison
would fail entirely if the connection has transient/always-ask secrets.
'vperic' had an interesting problem on IRC where every 10 minutes
the ethernet would change state from ACTIVATED -> DISCONNECTED with
a reason code of 0; the only thing I can find is that something was
telling NM to activate a connection periodically, becasue that appears
to be the only place that changes state to DISCONNECTED with a
reason code of 0. No logging; no apparent carrier changes.
So log this condition just in case we run into it later.
The keyfile code has to handle a few different formats of cert/key values,
and wasn't doing a good enough job of detecting plain paths as values. By
default the writer will write out a plain path (ie, not prefixed with file://)
and the reader will handle that correctly, *unless* that file does not
exist, at which the reader assumed it was a byte array. This caused the
read-in keyfile not to match the in-memory connection (since the in-memory
connection though the cert/key held a path, but the read-in one thought it
contained a blob) and this seems to eventually have triggered a write-out
with the new values (as a blob), which would then drop a .pem file into
system-connections/ containing the path that should have been in the
keyfile in the first place.
This all happened because we assumed that the given path for the cert or
key would actually be valid, which doesn't seem to be the case for a lot
of people. Clearly these connections won't work (since the certificate or
key does not exist) but the keyfile plugin shouldn't be messing up the
connection's settings at the very least.
Fix that by handling the check of whether the cert/key data is a path or
not in a less restrictive manner and add some testcases to make sure that
everything works as we expect.
If the cert/key path is relative to the keyfile then don't
bother writing the absolute path out. This also prevents the
keyfile plugin from rewriting a relative path to an absolute one,
preventing some annoyance for people that hand-edit keyfiles.
Passing a relative path to wpa_supplicant does no good since the supplicant
may not have the same working directory as NetworkManager. Relative paths
used in keyfiles are assumed to be relative to the keyfile itself anyway,
so actually use the absolute path we compute for the cert/key instead of
leaving it relative.
Since the keyfile plugin only stores the paths of these files,
we don't really care about what's in them. We also don't want
to attempt to read them as keyfiles, which produces warnings
in the logs.
G_VALUE_HOLDS will fail if the value variable is NULL, so we only
want to check that the GValue holds the right type if the value
is valid. NULL means "no object path" in demarshallers.
Since D-Bus doesn't allow NULL or zero-length object paths, NM
uses "/" as a placeholder here. Make sure the generic marshalling
code handles that so we don't have to do it in multiple places and
simplify handling of NULL objects somewhat.
Enables easier traversal of the object hierarchy; if a client is
watching signals on a device they can easily get back to the
parent NMActiveConnection object to grab connection details or
status.
Here's the problem:
- NM requests secrets
- secret agent returns secrets including some that are agent-owned or
not-saved (ie, transient secrets)
- for whatever reason (other secrets are system-owned, whatever) the
connection gets written back out to disk
- at some point later inotify triggers a connection re-read from disk
- the connection is read from disk, but doesn't contain the agent-owned
or not-saved secrets, because they obviously don't get saved
- nm_settings_connection_replace_and_commit() blows away the agent-owned
or not-saved secrets that the agent originally returned
- device activation no longer has the transient secrets
Re-reading connection data from disk shouldn't change transient secrets;
instead we need to merge the just-read system-owned secrets with whatever
transient secrets an agent sent. Transient secrets should only be cleared
by nm_connection_clear_secrets() to ensure that they stick around for as
long as we need them.
This used to only happen for user-created APs, but the supplicant
always wants a frequency no matter what, and the kernel drivers will
normally merge with any other IBSS with the same SSID no matter what
frequency is used, so we might as well just pass something since
it doesn't really matter in the end anyway.
As a bonus we get to remove the user_created stuff since it doesn't
really matter much anymore.
Commit e083cd5c63 stopped openconnect from
saving its secrets. It'd been working for a whole three minutes since my
previous commit.
We need to have at least one secret with an *extant* flags setting of
NM_SETTING_SECRET_FLAG_NONE, in order to trigger a write-out of the new
set of secrets. And we might as well list all the secrets we *know* the
auth-dialog is going to use, although we know there will be some secrets
that we cannot predict in advance (the form entry boxes).
All non-VPN secrets are considered system-owned if they do not
have any explicitly set secret flags, and this makes VPN secrets
treated the same way. As part of the import process plugins and
the applet already update secret flags. This ensures that VPN
secrets are treated consistently throughout the codebase.
Retries counter was not initialized when connections were loaded. That forced
the counter to start from -1 and continue decreasing on connection failures.
And connection attempts never stopped.
Instead of just with the old environment variable. This means we'll
log pppd debug output when the log level is changed via the D-Bus
interface now too.
Previously a secret marked NOT_SAVED or NOT_REQUIRED would be
treated as a system secret when checking returned secrets. That's
incorrect since unsaved or not required secrets aren't stored
by system settings.
Evil hack; but the problem is that before this commit anyone who
migrated connections wouldn't have the right secrets flag set in
their openconnect connections. Figuring out some way of updating
those connections now is harder and we don't want people to have
to go through the delete-connection-file-change-applet-stamp-rerun
dance. So we'll live with this for now...
Use one global PolkitAuthority object; we only really need to use it
in one place anyway. So consolidate the code that uses polkit into
nm-manager-auth.c.
