Even with the previous fix some cases were still undistinguishable. For example,SSID like '11;12;' is both valid an intlist and a string.
So this commit:
- escapes ';' character with '\' when writing, and removes '\' while reading
This clearly differentiates between intlist x strings.
- changes regex pattern to allow spaces before ';' in intlist format
Intlists have to end with a ';' since that's how they are written
out, and that's the only way we can actually distinguish between
intlist SSIDs and string SSIDs, really.
When connection was changed with the editor from WPA to WEP, KEY_MGMT was
not cleared. This resulted in infinite loop of ifcfg plugin under some
circumstances ("Available to all users" unchecked, I think).
The re-read connection was regarded as WPA and thus it differed from the
stored one.
NM already includes <linux/if.h> in some places, f.e. nm-netlink-monitor and
we can't mix usage of the two. Stick to using <linux/if.h> as it provides
additional flag definitions such as operational link state and link mode.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
SSIDs don't want NULL termination, but some of the certificate code
checked for it. New-style plain strings would never be NULL
terminated (by accident) so fix that and make the code simpler too.
Found by Gary Ching-Pang Lin <chingpang@gmail.com>
When a default wired connection is saved, it gets deleted first since it
has to be re-created using a settings plugin. But with the settings
rework in 0.9, default wired refcounting changed and the default
wired connection wasn't kept alive in default_wired_try_update()
over the removal/readd. This caused a use-after-free.
* When a connection name (ID) was changed via nm-connection-editor, a new file
path was created, but the old one was not removed. That resulted in two files
and in turn in duplicated connections.
* When two connections with the same name (ID) were present, e.g. files ABC and
ABC-70656842-98ac-4221-aa8b-0d4174770, and nm-connection-editor was used to
edit ABC-70656842-98ac-4221-aa8b-0d4174770, the operation failed.
What we want to do here is keep separate caches of system and
agent secrets. For system secrets, we cache them because NM
periodically clears secrets using nm_connection_clear_secrets() to
ensure they don't stay around in memory, and that transient secrets
get requested again when they are needed. For agent secrets, we
only want them during activation, but a connection read from disk
will not include agent secrets becuase by definition they aren't
stored in system settings along with the connection. Thus we need
to keep the agent/transient secrets somewhere for the duration of
the activation to ensure they don't get deleted.
This removes the copy-back hack in update_auth_cb() which copied
agent/transient secrets back into the connection over top of the
transient secrets that had been copied back in
nm_settings_connection_replace_settings(). No reason to copy
them twice if we keep an agent/transient secrets hash and do
the right thing with it.
The core problem was that the Update would trigger a write to
disk to save the connection's new settings, which called
nm_settings_connection_replace_settings(). Which saved existing
transient (agent/unsaved) secrets, replaced settings with the
new ones from Update(), then copied back the old transient
secrets. This was to ensure that changes triggered from getting
agent secrets during activation (which might write the connection
out to disk if new system secrets were provided, which triggered
an inotify read-back of the connection, which blew away the
transient secrets just returned from the agent) didn't blow away
transient secrets. Unfortunately that fix was too general.
As a quick hack for now, copy the new secrets and re-apply them
after nm_connection_replace_settings() has run. We'll do the
actual fix later, but it's more involved and needs more testing
so we don't want to apply it this close to release.
Changing NM_CONTROLED from "no" to "yes" worked just the first time.
Fix that by storing unmanaged spec when interface becomes unmanaged
and adjust condition identifying "no-change" updates to the ifcfg
file.
Chain up to parent's commit_changes() even if in-memory and on-disk data are the
same; they are the same when another process changes the on-disk file. Just make
sure not to write out the data needlessly when same.
This fixes a regression caused by 9cba854fa0.
It exhibits e.g. by not auto-activating connection when ONBOOT is changed from
"no" to "yes". Connection "updated" signal was not emitted and listeners like
NMPolicy was not prodded.
The regex was capturing integers larger than 3 digits, which aren't
valid SSID integer list items because each byte of the SSID cannot be
larger than 255. Add an explicit testcase for intlist SSIDs too.
The previous regex was causing a testcase failure with an SSID of
'1337' which it was interpreting as a single element intlist, but
should have been interpreted as a string since it's clear > 255.
When secrets are flagged as agent-owned in a connection configuration file, but
actually not available, we have to return an empty hash (nm_connection_to_hash()
returns NULL).
It's not a valid prefix since NM determines the default routes
automatically, and thus routes and addresses with a prefix of
zero should not be used in config files.
Use case:
A user has an auto-activatable connection with secrets in a keyring. While
booting NM starts and tries to activate the connection, but it fails because of
missing secrets. Then the user logs in, but the connection is marked as invalid
and is not tried again.
This commit solves the issue by removing invalid flag and activating the
connection when a secret agent registers.
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
ifcfg-rh plugin now reads/writes the property as MACADDR_BLACKLIST variable.
The variable is space-separated list of MAC addresses in the standard
hex-digits-and-colons notation.
E.g. MACADDR_BLACKLIST="7e:d8:c0:85:58:7f 00:1e:65:30:d5:c7"
IPV6_FAILURE_FATAL is now read and defaults to TRUE for ifcfg files
even if IPv6 is turned off. That means that if we write a connection
for which NM_SETTING_IP6_CONFIG_MAY_FAIL is FALSE but IPv6 is disabled,
ifcfg-rh won't write out IPV6_FAILURE_FATAL (because IPv6 is disabled
so why bother writing out IPv6-related settings) but on re-read it will
treat the absence of IPV6_FAILURE_FATAL as TRUE/yes. This leads to
a mismatch between the connection that was written out (which will
have NM_SETTING_IP6_CONFIG_MAY_FAIL=FALSE and no IPV6_FAILURE_FATAL)
and the re-read connection (which will have
NM_SETTING_IP6_CONFIG_MAY_FAIL=TRUE since a missing IPV6_FAILURE_FATAL
is treated as NM_SETTING_IP6_CONFIG_MAY_FAIL=TRUE).
We need to read IPV6_FAILURE_FATAL and other values, even if IPv6 is disabled.
Else the variables would use default values, which may not be right. Then
switching between methods "Ignore" and "Automatic" in a GUI would change value of
IPV6_FAILURE_FATAL property, even if it's not touched explicitly.
The core problem was the nm_connection_need_secrets() call in
nm-agent-manager.c's get_start() function; for VPN settings this
always returns TRUE. Thus if a VPN connection had only system
secrets, when the agent manager checked if additional secrets
were required, they would be, and agents would be asked for
secrets they didn't have and couldn't provide. Thus the
connection would fail. nm_connection_need_secrets() simply
can't know if VPN secrets are really required because it
doesn't know anything about the internal VPN private data;
only the plugin itself can tell us if secrets are required.
If the system secrets are sufficient we shouldn't be asking any
agents for secrets at all. So implement a three-step secrets
path for VPN connections. First we retrieve existing system
secrets, and ask the plugin if these are sufficient. Second we
request both existing system secrets and existing agent secrets
and again ask the plugin if these are sufficient. If both those
fail, we ask agents for new secrets.
Previously (in NM 0.8.x) most WiFi connection were from user settings service.
And the service updated 'seen-bssids' property when got connected.
But the settings service in 0.9 don't do that. That inhibits auto-connecting to
hidden networks. This commit takes care of updating 'seen-bssids'. However, we
don't want to write out the conection each time it's activated (touching /etc).
So, seen BSSIDs are kept separately from the connection in a look-aside file.
Signed-off-by: Jiří Klimeš <jklimes@redhat.com>
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.
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.
