summaryrefslogtreecommitdiff
path: root/src/nm-netns.c
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2019-07-12 11:19:43 +0200
committerThomas Haller <thaller@redhat.com>2019-07-15 16:48:21 +0200
commit17260210119cf902239c79fb9358bc81075f3f7a (patch)
treea8074836333180de491af9df40c3346d414f37cf /src/nm-netns.c
parentfe6b0736b848d96ddd8c7e0bc0c8e74287ae9ebd (diff)
downloadNetworkManager-th/routing-rule-suppress-prefixlength.tar.gz
policy-routing: take ownership of externally configured rulesth/routing-rule-suppress-prefixlength
IP addresses, routes, TC and QDiscs are all tied to a certain interface. So when NetworkManager manages an interface, it can be confident that the entires should be managed, deleted and modified by NetworkManager. Routing policy rules are global. For that we have NMPRulesManager which keeps track of who owns a rule. This allows multiple connection profiles specify the same rule, and NMPRulesManager can consolidate this information to know whether to add or remove the rule. NMPRulesManager would also support to explicitly block a rule, but that is currently not used. All that devices do is to add rules (track) and remove them (untrack) once the profile gets deactivated. As rules are not exclusively owned by NetworkManager, NetworkManager tries not to interfere with rules that it knows nothing about. That means in particular, when NetworkManager starts it will "weakly track" all rules that are present. "weakly track" is mostly interesting for two cases: - when NMPRulesManager had the same rule explicitly tracked (added) by a device, then deactivating the device will leave the rule in place. - when NMPRulesManager had the same rule explicitly blocked (tracked with negative priority), then it would restore the rule when that block gets removed (as said, currently nobody actually does this). Note that when restarting NetworkManager, then the device may stay and the rules kept. However after restart, NetworkManager no longer knows that it previously added this route, so it would weakly track it and never remove them again. That is a problem. Avoid that, by whenever explicitly tracking a rule we also make sure to no longer weakly track it. Most likely this rule was indeed previously managed by NetworkManager. If this was really a rule added by externally, then the user really should choose distinct rule priority to avoid such conflict altogether.
Diffstat (limited to 'src/nm-netns.c')
-rw-r--r--src/nm-netns.c16
1 files changed, 13 insertions, 3 deletions
diff --git a/src/nm-netns.c b/src/nm-netns.c
index de822151af..f5669c6617 100644
--- a/src/nm-netns.c
+++ b/src/nm-netns.c
@@ -127,17 +127,27 @@ constructed (GObject *object)
priv->rules_manager = nmp_rules_manager_new (priv->platform);
- /* Weakly track the default rules and rules that were added
- * outside of NetworkManager. */
+ /* Weakly track the default rules with a dummy user-tag. These
+ * rules are always weekly tracked... */
nmp_rules_manager_track_default (priv->rules_manager,
AF_UNSPEC,
0,
nm_netns_parent_class /* static dummy user-tag */);
+
+ /* Also weakly track all existing route. These were added before NetworkManager
+ * starts, so it's probably none of NetworkManager's business.
+ *
+ * However note that during service restart, devices may stay up and rules kept.
+ * That means, after restart such rules may have been added by a previous run
+ * of NetworkManager, we just don't know.
+ *
+ * For that reason, whenever we will touch such rules later one, we make them
+ * fully owned and no longer weekly tracked. See %NMP_RULES_MANAGER_EXTERN_WEAKLY_TRACKED_USER_TAG. */
nmp_rules_manager_track_from_platform (priv->rules_manager,
NULL,
AF_UNSPEC,
0,
- nm_netns_parent_class /* static dummy user-tag */);
+ NMP_RULES_MANAGER_EXTERN_WEAKLY_TRACKED_USER_TAG);
G_OBJECT_CLASS (nm_netns_parent_class)->constructed (object);
}