NetworkManager does not allow default routes to be specified
as normal routes. They must be ignored. Especially, iproute2
which reads the ifcfg files in initscripts, does not allow
to specify a prefix length "default/x" except for "default/0".
https://bugzilla.gnome.org/show_bug.cgi?id=761631
The @read_wired_static array is passed on as test function. But defining
it in a local scope is strictly speaking not correct because the lifetime
of the array ends before the test run. Move it to the outer scope, which
exists during the test runs.
Since commit bb868770, setting a gateway of "0.0.0.0"
or "::" in NMSettingIPConfig means to set the gateway
to NULL. There is indeed no difference between an unset
gateway and an any gateway. This change was done to have
a consistent behavior in NMSettingIPConfig.
Fixes: bb86877031
Two of these raised Coverity's eyebrows.
CID 59389 (#1 of 1): Insecure temporary file (SECURE_TEMP)
5. secure_temp: Calling mkstemp without securely setting umask first.
CID 59388 (#1 of 1): Insecure temporary file (SECURE_TEMP)
1. secure_temp: Calling mkstemp without securely setting umask first.
Last one raised mine.
When a connection is edited and saved, there's a small window during which and
unprivileged authenticated local user can read out connection secrets (e.g. a
VPN or Wi-Fi password). The security impact is perhaps of low severity as
there's no way to force another user to save their connection.
CID 59382 (#1 of 1): Dereference null return value (NULL_RETURNS)
10. dereference: Dereferencing a pointer that might be null value
when calling strcmp.
Not exactly true, since we ruled out the posibility earlier; but
we could still get rid of a couple of strcmps.
We inconsistently use gulong,guint,int types to store signal handler
id, but the type returned by g_signal_connect() is a gulong.
This has no practical consequences because a int/guint is enough to
store the value, however it is better to use a consistent type, also
because nm_clear_g_signal_handler() accepts a pointer to the signal id
and thus it must be always called with the same pointer type.
Previously, we directly passed the @in_ifcfg path to find_by_path().
That means, @in_ifcfg must be the path to the base "ifcfg-" file,
not an alias or route file.
Add an additional pre-check, that the provided file name is really a
ifcfg base file.
This results in a more detailed error message when calling
GetIfcfgDetails not on the ifcfg base file. It's not that previously
the lookup would have succeeded.
Up to now, the "include" directory contained (only) header files that were
used project-wide by libs, core, clients, et al.
Since the directory now also contains a non-header file, the "include"
name is misleading. Instead of adding yet another directory that is
project-wide, with non-header-only content, rename the "include"
directory to "shared".
This enum was unused and meaningless because the platform signals
are emitted as a consequence of netlink messages. It is not clear
whether a netlink message was received due to an external event
or an internal action.
Can't just substitute sysconfdir into a header file -- it's meant to be
expanded in a Makefile. Otherwise, unexpanded ${prefix} will end up in a
header file.
We do that for NMCONFDIR already, let's use it here too.
Fixes: 2144457fab
These properties limit whether the connection applies to a certain WWAN modem
based on the modem's device ID or SIM ID (as reported by the WWAN management
service), or through the MCC/MNC ID of the operator that issued the SIM card.
Old init-scripts that did not yet understand this key will have
mac-address-randomization explicitly disabled. This is to ensure
that old connections don't change behavior.
Thus, the writer must always write the value explicitly.
Downside is, if somebody creates a quick ifcfg-file, the feature
is disabled by default.
Prevsiouly, the ifcfg-rh service and the regular NetworkManager
were both exported on the same D-Bus connection. That had the
effect, that on both services ("com.redhat.ifcfgrh1" and
"org.freedesktop.NetworkManager") all objects were visible.
This is also problematic later when we use GDBusObjectManager
for the org.freedesktop.NetworkManager service.
Export the ifcfg service on a separate bus connection.
One downside is, that we don't bother exporting the service
on the private socket and thus the service is not available
without D-Bus daemon.
Also, if the bus disconnects, we don't retry or recover. Instead
the D-Bus service is dead until restart.
Take a missing value in keyfile/ifcfg-rh as EUI-64 to keep the compatibility
with the old conneciton. Nevertheless, the new connections should default to
the RFC7217 addresses.
Initscripts do:
oldifs=$IFS;
IFS=';';
[ -n "${ETHTOOL_DELAY}" ] && /bin/usleep ${ETHTOOL_DELAY}
for opts in $ETHTOOL_OPTS ; do
IFS=$oldifs;
if [[ "${opts}" =~ [[:space:]]*- ]]; then
/sbin/ethtool $opts
else
/sbin/ethtool -s ${REALDEVICE} $opts
fi
IFS=';';
done
IFS=$oldifs;
thus, we want to split on ';', otherwise we parse
"wol d;something else"
wrong.
Also, g_strsplit_set() returns multiple empty tokens. So
we must skip over empty tokens in case of "wol d".
The @use_password was wrong, because we would warn if sopass is specified
before wol:
"sopass AA:BB:CC:DD:EE:FF wol g"
More resilently handle wrong configurations:
"wol pu wol m" => gives m.
"wol pu wol" => should give NONE and warn (instead of "pu").
Also accept tab as separator.
Add a new 'ignore' option to NMSettingWired.wake-on-lan which disables
management of wake-on-lan by NetworkManager (i.e. the pre-existing
option will not be touched). Also, change the default behavior to be
'ignore' instead of 'disabled'.
https://bugzilla.gnome.org/show_bug.cgi?id=755182
Dracut when faced with an ipv6 only setup during kickstart will generate a ifcfg
file that sets the ipv4 address things to null but sets BOOTPROTO=static. This
makes network manager screw up because it expects an ipv4 address to be set.
Instead deal with this case by checking if we have any ipv4 addrs set, and if
not just disable ipv4. This fixes our inability to kickstart in our ipv6 only
clusters. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
https://mail.gnome.org/archives/networkmanager-list/2015-October/msg00015.html
Some initscripts variables can use "0" or "1" instead of more common
"yes", "no", for example REORDER_HDR.
And we also write REORDER_HDR=0|1 in writer.c, so we did not read REODER_HDR
correctly.
Fixes: ccea442504
The kernel defaults REORDER_HDR to 1 when creating a new VLAN, but
NetworkManager's VLAN flags property defaulted to 0. Thus REORDER_HDR was not
set for NM-created VLANs with default values.
We want to match the kernel default, so we change the default value for the
vlan.flags property. However, we do not want to change the flags for existing
connections if the property is missing in connection files. Thus we have to
update plugins for that. We also make sure that vlan.flags is always written
by 'keyfile' when the value is default. That way new connections have flags
property explicitly written and it will be loaded as expected.
https://bugzilla.redhat.com/show_bug.cgi?id=1250225
