When exporting an object, we first set the object path and then create
GDBus interface skeletons. While doing this, a signal can be generated
[1] and then nm_exported_object_signal_hook() can trigger the failed
assertion "interface != NULL" because the object is already exported
(priv->path != NULL) but the interface has not been registered yet.
To fix this, set the object path only after skeletons have been
created.
[1] This happens here every time I disable networking and restart NM:
#0 _g_log_abort (libglib-2.0.so.0)
#1 g_log (libglib-2.0.so.0)
#2 nm_exported_object_signal_hook (NetworkManager)
#3 signal_emit_unlocked_R (libgobject-2.0.so.0)
#4 g_signal_emit_valist (libgobject-2.0.so.0)
#5 g_signal_emit (libgobject-2.0.so.0)
#6 set_state (NetworkManager)
#7 nm_manager_update_state (NetworkManager)
#8 get_property (NetworkManager)
#9 object_get_property (libgobject-2.0.so.0)
#10 on_source_notify (libgobject-2.0.so.0)
#11 g_object_bind_property_full (libgobject-2.0.so.0)
#12 g_object_bind_property (libgobject-2.0.so.0)
#13 nm_exported_object_skeleton_create (NetworkManager)
#14 nm_exported_object_create_skeletons (NetworkManager)
#15 nm_exported_object_export (NetworkManager)
#16 nm_manager_setup (NetworkManager)
#17 main (NetworkManager)
#18 __libc_start_main (libc.so.6)
#19 _start (NetworkManager)
https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00041.html
They are actually u32 in the kernel. Plus if we use G_MAXINT32 it
causes gtkdoc to write out "Allowed values: <= G_MAXLONG" on i386
and "Allowed values: <= G_MAXINT" on x86_64, breaking multilib.
Fixes: 95dfd99afc
We detect support for IPv6 temporary addresses (IFA_F_MANAGETEMPADDR) or /64 v6 prefixes
(IFA_F_NOPREFIXROUTE) based on the presence of extended address flags. For the most part
this just works, but it fails down if upon initialization no addresses are present.
In such a case we would have assumed no support. Change that to default to available
support as the feature is already 2 years in upstream kernel.
Since commit 9ff161b2a1 ("device: move have_ip6_address() to
nm_ip6_config_get_address_first_nontentative()") the IP configuration
argument of nm_ip6_config_get_address_first_nontentative() must be
non-NULL. Add checks where needed.
Fixes: 9ff161b2a1
Fail only printed a message to stderr and exited.
Instead, print it with g_error(), which also breaks
in the debugger and produces a core-dump.
Also, it constructed the message based on an unchecked
format string and constructed a format string dynamically.
Just don't do that.
Also add a comment that these macros are discouraged because
they are cumbersome to write (requiring a test-name and a failure
message).
Also add a new conditional "debug" to enable more assertions and
more logging, which is disabled by default.
Also add a conditional "test" to disable running the unit tests
(make check) while building the package.
http://rpm.org/wiki/PackagerDocs/ConditionalBuilds
We should not check ip6_config for the link local address because
ip6_config contains the merged settings we want to configure,
not the addresses that are actually configured on the device.
Check ext_ip6_config_captured for that.
Also, reuse nm_ip6_config_get_address_first_nontentative() which
only takes an address after it survived DAD.
The compiler might be able to optimize the switch better.
But more importantly, it has the type information of the enum
and can give warnings about unmentioned enum values.
Drivers are stupid, and just like the platform ignores an all zeros
permanent address, so should it ignore all ones.
NetworkManager[509]: <debug> [1453743778.854919] [devices/nm-device.c:8885] nm_device_update_hw_address(): [0x190370] (eth0): hardware address now 86:18:52:xx:xx:xx
NetworkManager[509]: <debug> [1453743778.855438] [devices/nm-device.c:9138] constructed(): [0x190370] (eth0): read initial MAC address 86:18:52:xx:xx:xx
NetworkManager[509]: <debug> [1453743778.861602] [devices/nm-device.c:9148] constructed(): [0x190370] (eth0): read permanent MAC address FF:FF:FF:FF:FF:FF
It will only be in ext_ip6_config if it was added by the kernel,
which isn't usually the case since NM handles IPv6LL address
generation on new enough kernels.
If the LL address isn't found, IPv6 configuration will never
complete because DHCPv6 was started already but lack of an LL
address bails out early without handling the error.
Fixes: b8c2fc26c1
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.
Coverity is angry:
CID 59367 (#1-3 of 3): Division or modulo by float zero (DIVIDE_BY_ZERO)
30. divide_by_zero: In expression
((double)max_level - (double)level) /
((double)max_level - (double)noise),
division by expression (double)max_level - (double)noise which may be zero has
undefined behavior.
Can not fail no fake platform, but makes Coverity worried:
CID 59381 (#1 of 1): Dereference null return value (NULL_RETURNS)
6. dereference: Dereferencing a null pointer device.
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.
