If the user is AddAndActivating a new network, the connection may not
have an NMSettingConnection yet, but we know that once it does, the
user will be authorized.
nmtui was using local copies of some functions that were originally in
libnm-gtk. Move them into the appropriate places in libnm-util and
libnm-glib instead.
Utility function, to search the list of connections for a connection
with a matching id/name. Returns the first match.
Signed-off-by: Thomas Haller <thaller@redhat.com>
4f3a9cca6f stopped unescaping Team
configuration when reading ifcfg files due to inefficient algorithms
in svUnescape(). Unfortunately, since Team configuration is escaped
when written out, reading it in creates invalid configuration that
teamd rejects.
The pathological case was a 9MB invalid Team configuration. Since a
Team configuration will never, ever be that large, fix the issue by
warning the user or rejecting the configuration if it is over 20000
bytes in size (an arbitrary number). Thus svUnescape() will never
be called with huge strings, but the configuration is still unescaped.
https://bugzilla.redhat.com/show_bug.cgi?id=1051517
Polkit documentation suggests that <allow_any> applies to all
clients, but that's actually not the case. allow_any,
allow_inactive, and allow_active are evaluated individually based
on whether the user is local and active (allow_active), local and
inactive (allow_inactive), and not local (allow_any). Thus all
three allow options must be specified for any authorization other
than 'no'.
IPSec-based VPNs that use the kernel IPSec functionality don't have tunnel
interfaces. Instead, the IP addresses and routes they create are added
to the parent interface and the kernel handles securing the traffic based
on routing. Modify NM to handle this.
Also modify NM to ensure it doesn't touch routes added externally, and to
preserve various route properties correctly.
A gateway route can only be added, if there exists a device route
for that gateway. Therefore, nm_platform_ip4_route_sync() and
nm_platform_ip6_route_sync() has to add the device routes first,
before adding gateway routes.
Note: usually for all configured addresses, there is also a device
route for the subnet added by the kernel. This means, NM must first
configure the addresses before route_sync, so that these implicit device
routes already exist -- this is however already done correctly.
Signed-off-by: Thomas Haller <thaller@redhat.com>
If a route already exists that matches the network, prefix, gateway,
and metric of a route NM would like to add, don't try to overwrite
the route.
Unlike IP addresses, the kernel doesn't update the details, it
appears to completely replace that route, which might screw up
external tools that added the route originally.
One example of this is IPSec via openswan/libreswan. They add the
routes to the kernel upon connection, and if NM replaces those routes,
IPSec no longer works. While this may be due to kernel bugs or
bad handling of route replacement, there's no reason for NM to touch
routes that it wouldn't materially change anyway.
(yes, we could perhaps use NLM_F_REPLACE in add_kernel_object() only
when we really wanted to replace something, but why ask the kernel
to do the work when it's not required anyway?)
Two issues:
1) routes added by external programs or by users with /sbin/ip should not
be modified, but NetworkManager was always changing those routes' metrics
to match the device priority. This caused the nm_platform_ipX_route_sync()
functions to remove the original, external route (due to mismatched metric)
and re-add the route with the NetworkManager specified metric. Fix that
by not touching routes which came from the kernel.
2) Static routes (from persistent connections) that specified a metric were
getting their metric overwritten with the NetworkManager device priority.
Stop doing that.
Since the platform no longer defaults the metric to 1024, callers of
nm_platform_ip4_route_add() (like NMPolicy's default route handling)
must do that themselves, if they desire this behavior.
Tag addresses and routes with their source. We'll use this later to do
(or not do) operations based on where the item came from.
One thing to note is that when synchronizing items with the kernel, all
items are read as source=KERNEL even when they originally came from
NetworkManager, since the kernel has no way of providing this source
information. This requires the source 'priority', which
nm_ip*_config_add_address() and nm_ip*_config_add_route() must respect
to ensure that NM-owned routes don't have their source overwritten
when merging various IP configs in ip*_config_merge_and_apply().
Also of note is that memcmp() can no longer be used to compare
addresses/routes in nm-platform.c, but this had problems before
anyway with ifindex, so that workaround from nm_platform_ip4_route_sync()
can be removed.
https://bugzilla.gnome.org/show_bug.cgi?id=722843https://bugzilla.redhat.com/show_bug.cgi?id=1005416
VPN services that use the kernel's IPSec stack (like OpenSwan/LibreSWAN)
obviously don't have a tunnel interface, so don't require one. If
those services provide Link-Local IPv6 DNS servers they simply won't
work, but perhaps we can filter those out later or warn about them.
Add properties for things that previously were missing to help out
Qt bindings, among others. Also converts libnm-glib over to use the
new properties, and adds some testcases to ensure libnm-glib works
correctly with them.
https://bugzilla.gnome.org/show_bug.cgi?id=715186
