Hm. It's not clear what the actual user impact of this is?
Reading from the original description, it seems that if a user uses an
invalid label to set one address and *also* uses a valid label to set
another address *then* tools can be confused?
“Our parser is actually more lenient than the manpage states” on its own
is definitely not SRU-worthy, but if it breaks other tools then maybe?
On the other hand, from the bug it looks like if you *don't* mix valid
and invalid labels then everything actually works? So this would
potentially be breaking currently working setups?
I think we need more information before determining whether this should
be accepted as an SRU.
** Changed in: iproute2 (Ubuntu Bionic)
Status: Triaged => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iproute2 in Ubuntu.
https://bugs.launchpad.net/bugs/1662620
Title:
"ip addr add" permits illegal labels
Status in iproute2 package in Ubuntu:
Fix Released
Status in iproute2 source package in Bionic:
Incomplete
Bug description:
[Impact]
* The filter on label names does not match the intention
by upstream nor the description in the man page
* Fix by backporting upstream fix that strengthens the check
[Test Plan]
Bad case:
root@b:~# ip addr add 1.1.1.1 label test1 dev eth0
"dev" (eth0) must match "label" (test1).
root@b:~# ip addr add 1.1.1.1 label eth0-test dev eth0
root@b:~# ip addr show dev eth0 | grep test
inet 1.1.1.1/32 scope global eth0-test
With the fix it should look like:
root@i:~# ip addr add 1.1.1.1 label test1 dev eth0
"label" (test1) must match "dev" (eth0) or be prefixed by "dev" with a colon.
root@i:~# ip addr add 1.1.1.1 label eth0-test dev eth0
"label" (eth0-test) must match "dev" (eth0) or be prefixed by "dev" with a
colon.
root@i:~# ip addr show dev eth0 | grep test
[Where problems could occur]
* While the fix indeed "corrects" behavior I must say that if someone
relied on the non-intended behavior it would now break e.g. his
scripting or automation.
[Other Info]
* It was too easy to fix and too long dormant to ignore it further,
but if the SRU team says this is too much regression risk relative to
the gain we will mark it Won't Fix based on that decision.
---
ip-address(8) manpage states:
label NAME
Each address may be tagged with a label string. In order to preserve
compatibility with Linux-2.0 net aliases, this string must coincide with the
name of the device or must be prefixed with the device name followed by colon.
But you can omit the colon, "ip addr add" is ONLY checking the label
is prefixed with the device:
# ip addr add 1.1.1.1 label test1 dev eth0
"dev" (eth0) must match "label" (test1).
# ip addr add 1.1.1.2 label eth0-test2 dev eth0
# ip addr add 1.1.1.3 label eth0:test3 dev eth0
Now ifconfig becomes confused about eth0-test2:
# ifconfig eth0-test2
eth0-test2: error fetching interface information: Device not found
# ifconfig eth0:test3
eth0:test3 Link encap:Ethernet HWaddr b0:d5:cc:fe:1d:7c
inet addr:1.1.1.3 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:171
And daemons like ntpd also log errors about the interface with the
illegal label:
ntpd[7570]: eth0-test3: getting interface flags: No such device
## => many of this error per minute until:
ntpd[7570]: Too many errors. Shutting up.
So, I think ip addr show disallow adding address with illegal (as
stated by his own documentation) labels, it must also check for the
colon following the dev name.
Version: 4.3.0-1ubuntu3
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1662620/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
