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.
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.
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.
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.
If the client knows the UUID, add a convenience function to get
the connection path directly, instead of having to iterate the
whole connection list and get each connection's details and then
check the UUID.
The signal was emitted in case the removed connection was managed instead of
for unmanaged connection. Thus the signal had no effect.
That caused incorrect behaviour in case of changing NM_CONTROLLED=no to yes.
That didn't enable the device; only after the file was changed for the second time.
The default wired connection should own a reference to the device
it's made for, but that got dropped in
78df8c49a1, which used to use a
set_property handler with g_value_dup_object() which obviously
increments the reference count. But that ref got dropped when
the object initialization was simplified.
Now that initscripts also support IPADDRn syntax, update the implementation
to match the intitscripts' one (see rh #633984)
Basically, writer produces IPADDR0 .. IPADDR255. reader is more tolerant and
supports older configs too: IPADDR, IPADDR0, IPADDR1 could be missing, from
IPADDR2 up the indexes have to be contiguous.
Due to an error in the loop logic, if there were no connections yet (like
a fresh install or a livecd or whatever) no default name would be returned
and thus ethernet devices wouldn't come up automatically. Fix that loop
error and add testcases for it.
If the connection had system secrets, previously the settings core
would consider those sufficient even if the device code had requested
new secrets because the old ones didn't work.
Where 'x' is a number that's not yet used by any existing connection.
And clean up the default wired class initialization. This name is
more friendly than "Auto eth0" which was confusing to quite a few
people. This also checks to ensure there's no other connection with
the same name, which the old method did not.
Suggested by Jon McCann.
These are distinct from old-school LEAP (ie, Network EAP) in that
they are standard Dynamic WEP with LEAP as an EAP method and use
open-system authentication. Old LEAP uses the non-standard LEAP
authentication algorithm. The config for each is different and thus
we need to make sure we handle both cases.
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.
