Otherwise the types links would be dangling or resolved to slightly
irrelevant documentation in libnm or completely irrelevant documentation
in libnm-util.
(cherry picked from commit db6ebe003d)
It isn't right in that context -- NMDevice is a libnm-core object,
not a bus object. In rendered documentation this would generate
a dangling link.
(cherry picked from commit c850868faf)
When mounting /proc with hidepid, we might fail to read the
start-time of the process from /proc/$PID/stat. In this case,
we should just accept a start-time of zero.
On the other side of authentication, polkit should accept a zero
start-time too.
nm_utils_get_start_time_for_pid() has other uses in NetworkManager,
mostly when killing a process from a PIDFILE or during
nm_utils_kill_process_sync(). In both these cases, this will only
succeed if we try to kill a process that also runs a root.
For processes started by the current instance, we don't care about the
PIDFILE and use nm_utils_kill_child_?sync() -- so there is no problem
with hidepid there.
https://bugzilla.gnome.org/show_bug.cgi?id=764502
(cherry picked from commit 3d505b3f87)
Pass an empty configuration file otherwise dnsmasq loads
"/etc/dnsmasq.conf".
We already allow for a config.d/ directory "/etc/NetworkManager/dnsmasq.d"
to allow the user to overwrite configuration. We don't want to consider
the global config file.
Fixes: 497a8aa5c6
(cherry picked from commit 3d3f71acec)
The 4 private fields pid, watch_id, progname and pidfile strictly
belong together. When spawning a child, we set all 4 of them and
when killing the child all get cleared. Cleanup to code to always
set those 4 fields together.
(cherry picked from commit 4d5ca7f9de)
When NetworkManager exits, it must preserve the DNS configuration of
devices that are left up.
Fixes: 9498ea507e
(cherry picked from commit 2158d6a5a8)
Otherwise NetworkManager can be too fast calling a method:
<error> [1461073999.2362] vpn-connection[0x7fe39ec491e0,be049803-a705-438f-b8f5-49db87640c93,"libreswan",0]:
plugin NeedSecrets request #1 failed: No such interface 'org.freedesktop.NetworkManager.VPN.Plugin'
on object at path /org/freedesktop/NetworkManager/VPN/Plugin
(cherry picked from commit 843a05f7cc)
The infiniband drivers don't implement the rtnetlink link deletions.
Therefore we unrealize the NMDevice instance but the backing resources
stay around, preventing us from ever realizing the device again.
(cherry picked from commit a93807c288)
nmcli> set 802-1x.ca-cert file:///tmp/certs/eaptest_ca_cert.pem
(process:31015): libnm-CRITICAL **: crypto_is_pkcs12_data: assertion 'data != NULL' failed
Error: failed to set 'ca-cert' property: PEM certificate had no start tag '-----BEGIN CERTIFICATE-----'.
(cherry picked from commit 1d66d415b8)
In commit ca000cffbb, we changed to
accept a plugin library name without path. One reason for that
is to keep architecture dependent parts out of the .name file
and possibly support multilib.
However, the shared libraries of VPN plugins are not installed in
a global library search path, but for example into
"/usr/lib64/NetworkManager/libnm-vpn-plugin-openvpn.so".
In that case, specifying "plugin=libnm-vpn-plugin-openvpn.so"
would not be enough to find plugin.
Instead, when configuring a plugin name without path, assume
it is in NMPLUGINDIR directory. Modify nm_vpn_editor_plugin_load_from_file()
to allow path-less plugin-names. Previously such names would be rejected
as not being absolute. This API allows to do file verification
before loading the plugin, but it now supports prepending NMPLUGINDIR
to the plugin name. Basically, this function mangles the plugin_name
argument and checks that such a file exists.
The recently added nm_vpn_editor_plugin_load() continues to behave
as before: it does no checks whatsoever and passes the name directly
to dlopen(). That way, it uses system search paths like LD_LIBRARY_PATH
and performs no checks on the file.
Fixes: ca000cffbb
(cherry picked from commit 0b128aeced)
Since commit 3dfbbb227e, we enforce that
the plugin path in the .name file is absolute and we perform several
checks on the file before loading it (ownership, etc).
Relax that, to also allow libray names without path component.
In that case, g_module_open()/dlopen() will search for a library
in various search paths. This allows, to omit absolute paths
in the .name file. The latter is problematic, because by default
we install the .name file in the architecture independent location
/usr/lib/NetworkManager. As such, it should not contain paths
to architecture dependent libraries. With this change, a .name
file can contain only the library name and it will be loaded
using the usual mechanism.
However, specifying absolute paths is still possible and works
same as before, including checking file permissions.
As such, distributions probably should package the VPN plugins
to have no path in the .name file. On the other hand, a user
compiling from source probably wants to specify an absolute
path. The reason is, that the user probably doesn't build the
plugin for multiple achitectures and that way, he can install
the plugin in a separate (private) prefix.
(cherry picked from commit ca000cffbb)
The @plugin_filename argument must be an absolute path.
That was changed later, but forgot to update the comment.
Fixes: 3dfbbb227e
(cherry picked from commit cb22f02588)
Instead of looking into the keyfile, lookup the "supports-multiple-connections" setting
in the "keys" hash. This has some behavioral difference:
- g_key_file_get_boolean() first does g_key_file_get_value(), and then
converts the string using the private g_key_file_parse_value_as_boolean()
function -- which is case-sensitive, accepts "true|false|0|1" and
considers only the text until the first whitespace.
- now, we put g_key_file_get_string() into the cache "keys" and
parse it with _nm_utils_ascii_str_to_bool(). The latter is
case insensitive, allows also "yes|no|on|off", strips whitespaces.
However, the difference is subtle and shouldn't matter.
The point of this change is to free "keyfile" after construction.
(cherry picked from commit 6878999ca3)
The device creation can be attempted if the name can be determined. It
alone is doesn't mean that there's a parent device -- the name could
just have been hardcoded in the connection.
NetworkManager[21519]: nm_device_get_ifindex: assertion 'NM_IS_DEVICE (self)' failed
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x5555557fb2e5 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd3d0) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x00007ffff4ec88c3 in g_logv (log_domain=0x5555557fb2e5 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd3d0) at gmessages.c:1046
#1 0x00007ffff4ec8a3f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1079
#2 0x00005555555d2090 in nm_device_get_ifindex (self=0x0) at devices/nm-device.c:562
#3 0x00005555555ef77a in nm_device_supports_vlans (self=0x0) at devices/nm-device.c:9865
#4 0x00005555555bf2f9 in create_and_realize (device=0x555555c549b0 [NMDeviceVlan], connection=0x555555b451e0, parent=0x0, out_plink=0x7fffffffd5f8, error=0x7fffffffd700) at devices/nm-device-vlan.c:225
#5 0x00005555555d5757 in nm_device_create_and_realize (self=0x555555c549b0 [NMDeviceVlan], connection=0x555555b451e0, parent=0x0, error=0x7fffffffd700) at devices/nm-device.c:1783
#6 0x0000555555688601 in system_create_virtual_device (self=0x555555af51c0 [NMManager], connection=0x555555b451e0) at nm-manager.c:1120
#7 0x000055555568894e in connection_changed (settings=0x555555ae8220 [NMSettings], connection=0x555555b451e0, manager=0x555555af51c0 [NMManager]) at nm-manager.c:1172
#8 0x0000555555693448 in nm_manager_start (self=0x555555af51c0 [NMManager], error=0x7fffffffda30) at nm-manager.c:4466
#9 0x00005555555d166f in main (argc=1, argv=0x7fffffffdba8) at main.c:454
(gdb)
Fixes: 332994f1b1
(cherry picked from commit 03584e420f)
If the connection specifies an interface name, it should never attach to
a device of a different name even if the factory thinks the connection
is compatible with the device.
This fixes an issue that caused the inifniband connections to attach to
different devices or partitions.
(cherry picked from commit 332994f1b1)
...not from the connection. Otherwise the o.fdo.NM.openswan connection
would try to use a name they're not allowed to use.
(cherry picked from commit 178c972fac)
When we want to preserve the default-route on cleanup, we must first
set it to assumed, before clearing it. Otherwise, NMDefaultRouteManager's
update() will delete the default route.
This is the oposite of the deconfigure case, where we first set it to
!has && !assumed, to force the route-manager to delete the route.
(cherry picked from commit 4697376f99)
