summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorLennartPoettering <mzninuv@0pointer.de>2013-01-07 20:41:17 +0000
committerZbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>2018-12-11 10:58:39 +0100
commit5536de5cc4442d8a098fb68511abedf0f2553765 (patch)
tree9bf43373d674846410115ebe6dc39aeb2e4d5567 /docs
parent7b1e4518e0d5d9c68340cefa830bc7196ef05e20 (diff)
downloadsystemd-5536de5cc4442d8a098fb68511abedf0f2553765.tar.gz
Diffstat (limited to 'docs')
-rw-r--r--docs/PredictableNetworkInterfaceNames.moin2
1 files changed, 1 insertions, 1 deletions
diff --git a/docs/PredictableNetworkInterfaceNames.moin b/docs/PredictableNetworkInterfaceNames.moin
index 7a4ec4018f..35a7ed4e82 100644
--- a/docs/PredictableNetworkInterfaceNames.moin
+++ b/docs/PredictableNetworkInterfaceNames.moin
@@ -4,7 +4,7 @@ Starting with v197 systemd/udev will automatically assign predictable, stable ne
== Why? ==
-The classic naming scheme for network interfaces applied by the kernel is to simply assign names starting with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable with modern technology this meant that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is not fixed. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes.
+The classic naming scheme for network interfaces applied by the kernel is to simply assign names starting with "eth0", "eth1", ... to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable with modern technology this means that as soon as multiple network interfaces are available the assignment of the names "eth0", "eth1" and so on is generally not predicatble. This can have serious security implications, for example in firewall rules which are coded for certain naming schemes, and which are hence very sensitive to changing names.
To fix this problem multiple solutions have been proposed and implemented. For a longer time udev shipped support for assigning permanent "ethXXX" names to certain interfaces based on their MAC addresses. This turned out to have a multitude of problems, among them: this required a writable root directory which is generally not availeble; the statelessness of the system is lost as booting an OS image on a system will result in changed configuration of the image; on many systems MAC addresses are not actually fixed, such as on a lot of embedded hardware and particularly on all kinds of virtualization solutions. The biggest of all however is that the userspace components trying to assign the interface name raced against the kernel assigning new names from the same "ethXXX" namespace, a race condition with all kinds of weird effects.