iproute2: enhance addr label validation
Subsystems (2)
PATCH 1/1 iproute2: enhance addr label validation
The ip addr command today rejects address labels that would break ifconfig. However, it allows some labels which still break it. Enhance enforcement to reject all known incompatible labels, and allow the existing -force option to allow someone to use a label even if it is not ifconfig compatible
Make existing -force option of ip addr add skip enforcement of ifconfig compatible address labels.
Change enforcement to properly reject labels that do begin with <devname> but are followed by a string that does not begin with colon.
The following changes since commit 4612d04d6b8f07274bd5d0688f717ccc189499ad:
tc class: Show class names from file (2015-03-15 12:27:40 -0700)
are available in the git repository at:
[email protected]:jharvell/iproute2.git addr-label-noncompat
for you to fetch changes up to 44931a448ac2b375c703cb79fb814ec575fe253b:
----------------------------------------------------------------
Joe Harvell (6):
Making -force option of ip command also allow address labels that are not backward-compatible with ifconfig. Note that even without this change the ip command does allow some incompatible address labels to be created. ifconfig depends on the labels beginning with <interface-name><colon>, but the ip command (even before the changes in this commit) only requires the prefix of the label to be <interface-name>. Thus, if you add a label such as eth0-media, it will be accepted by ip but ifconfig will barf on ifconfig -a. The motivation for this change is that the lenght allowed for a lable is small, so requiring a long prefix for ifconfig backwards compatibility limits the usefulness of the label. For embedded systems (or any system) where ifconfig
is not even installed, it is useful to be able to create longer labels.
Enhancing enforcement of ifconfig compatible label. Prior implementation allowed incompatible labels that started with dev but not dev:
Adding parentheses for clarity Removing code comment since it is now clearly spelled out in fprintf error message
Using strncmp instead of matches for clarity and to avoid extra strlen calls
Fixed indenting by replacing spaces with tabs Minor re-word of man page text
include/utils.h | 1 + ip/ip.c | 2 ++ ip/ipaddress.c | 12 +++++++++--- man/man8/ip.8 | 2 ++ 4 files changed, 14 insertions(+), 3 deletions(-)
include/utils.h +1 -0
@@ -25,6 +25,7 @@ extern char * _SL_;extern int max_flush_loops;extern int batch_mode;extern bool do_all; +extern bool require_ifconfig_compat;#ifndef IPPROTO_ESP #define IPPROTO_ESP 50
ip/ip.c +2 -0
@@ -37,6 +37,7 @@ int force = 0;int max_flush_loops =10 ;int batch_mode =0 ;bool do_all = false; +bool require_ifconfig_compat = true;struct rtnl_handle rth = { .fd =-1 };
@@ -246,6 +247,7 @@ int main(int argc, char **argv)exit (0 ); }else if (matches (opt,"-force" ) ==0 ) { ++force; + require_ifconfig_compat = false; }else if (matches (opt,"-batch" ) ==0 ) { argc--; argv++;
ip/ipaddress.c +9 -3
@@ -1691,11 +1691,17 @@ static int ipaddr_modify(int cmd, int flags, int argc, char **argv)fprintf (stderr,"Not enough information: \"dev\" argument is required.\n" );return -1 ; } -if (l &&matches (d, l) !=0 ) { -fprintf (stderr,"\"dev\" (%s) must match \"label\" (%s).\n" , d, l); +if ( require_ifconfig_compat && l) { +bool isCompat = false; +size_t dLen =strlen (d); +size_t lLen =strlen (l); +if (lLen >= dLen &&strncmp (d, l, dLen) ==0 ) + isCompat = (dLen == lLen || l[dLen] ==':' ); +if ( !isCompat ) { +fprintf (stderr,"\"label\" (%s) must either be \"dev\" (%s) or start with \"dev\" followed by a colon (%s:).\n" , l, d, d);return -1 ; + } } -if (peer_len ==0 && local_len) {if (cmd ==RTM_DELADDR && lcl.family ==AF_INET && !(lcl.flags &PREFIXLEN_SPECIFIED )) { fprintf(stderr,
man/man8/ip.8 +2 -0
@@ -54,6 +54,8 @@ First failure will cause termination of ip. Don't terminate ip on errors in batch mode. If there were any errors during execution of the commands, the application return code will be non zero. +This option also allows creation of address labels that may not be compatible with ifconfig. + .TP .BR "\-s" , " \-stats" , " \-statistics" Output more information. If the option
Hi Joe,
Quoted 5 lines · Joe Harvell
The ip addr command today rejects address labels that would break ifconfig. However, it allows some labels which still break it. Enhance enforcement to reject all known incompatible labels, and allow the existing -force option to allow someone to use a label even if it is not ifconfig compatible
I am concerned this will break existing users who are relying on setting labels that would now be rejected without using -force.
Quoted 14 lines
Make existing -force option of ip addr add skip enforcement of ifconfig compatible address labels.
Change enforcement to properly reject labels that do begin with <devname> but are followed by a string that does not begin with colon.The following changes since commit
4612d04d6b8f07274bd5d0688f717ccc189499ad:tc class: Show class names from file (2015-03-15 12:27:40 -0700)
are available in the git repository at:
[email protected]:jharvell/iproute2.git addr-label-noncompat
Quoted 7 lines
for you to fetch changes up to
44931a448ac2b375c703cb79fb814ec575fe253b:----------------------------------------------------------------
Joe Harvell (6):
Making -force option of ip command also allow address labels that are not backward-compatible with ifconfig. Note that even without this change the ip command does allow some incompatible address labels to be created. ifconfig depends on the labels beginning with <interface-name><colon>, but the ip command (even before the changes in this commit) only requires the prefix of the label to be <interface-name>. Thus, if you add a label such as eth0-media, it will be accepted by ip but ifconfig will barf on ifconfig -a. The motivation for this change is that the lenght allowed for a lable is small, so requiring a long prefix for ifconfig backwards compatibility limits the usefulness of the label. For embedded systems (or any system) where ifconfig
is not even installed, it is useful to be able to create longer labels.
Quoted 84 lines
Enhancing enforcement of ifconfig compatible label. Prior implementation allowed incompatible labels that started with dev but not dev:
Adding parentheses for clarity Removing code comment since it is now clearly spelled out in fprintf error message
Using strncmp instead of matches for clarity and to avoid extra strlen calls
Fixed indenting by replacing spaces with tabs Minor re-word of man page textSigned-off-by Joe Harvell <[email protected]>include/utils.h | 1 + ip/ip.c | 2 ++ ip/ipaddress.c | 12 +++++++++--- man/man8/ip.8 | 2 ++ 4 files changed, 14 insertions(+), 3 deletions(-)include/utils.h +1
-0@@ -25,6 +25,7 @@ extern char * _SL_;extern int max_flush_loops;extern int batch_mode;extern bool do_all; +extern bool require_ifconfig_compat;#ifndef IPPROTO_ESP #define IPPROTO_ESP 50ip/ip.c +2
-0@@ -37,6 +37,7 @@ int force = 0;int max_flush_loops =10 ;int batch_mode =0 ;bool do_all = false; +bool require_ifconfig_compat = true;struct rtnl_handle rth = { .fd =-1 };@@ -246,6 +247,7 @@ int main(int argc, char **argv)exit (0 ); }else if (matches (opt,"-force" ) ==0 ) { ++force; + require_ifconfig_compat = false; }else if (matches (opt,"-batch" ) ==0 ) { argc--; argv++;ip/ipaddress.c +9
-3@@ -1691,11 +1691,17 @@ static int ipaddr_modify(int cmd, int flags, int argc, char **argv)fprintf (stderr,"Not enough information: \"dev\" argument is required.\n" );return -1 ; } -if (l &&matches (d, l) !=0 ) { -fprintf (stderr,"\"dev\" (%s) must match \"label\" (%s).\n" , d, l); +if ( require_ifconfig_compat && l) { +bool isCompat = false; +size_t dLen =strlen (d); +size_t lLen =strlen (l); +if (lLen >= dLen &&strncmp (d, l, dLen) ==0 ) + isCompat = (dLen == lLen || l[dLen] ==':' ); +if ( !isCompat ) { +fprintf (stderr,"\"label\" (%s) must either be \"dev\" (%s) or start with \"dev\" followed by a colon (%s:).\n" , l, d, d);return -1 ; + } } -if (peer_len ==0 && local_len) {if (cmd ==RTM_DELADDR && lcl.family ==AF_INET && !(lcl.flags &PREFIXLEN_SPECIFIED )) { fprintf(stderr,man/man8/ip.8 +2
-1@@ -54,6 +54,8 @@ First failure will cause termination of ip. Don't terminate ip on errors in batch mode. If there were any errors during execution of the commands, the application return code will be non zero. +This option also allows creation of address labels that may not be compatible with ifconfig. + .TP .BR "\-s" , " \-stats" , " \-statistics" Output more information. If the option --To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 12 lines
Hi Joe,
Quoted 5 lines · Joe Harvell
The ip addr command today rejects address labels that would break ifconfig. However, it allows some labels which still break it. Enhance enforcement to reject all known incompatible labels, and allow the existing -force option to allow someone to use a label even if it is not ifconfig compatible
I am concerned this will break existing users who are relying on setting labels that would now be rejected without using -force.
[snip]
Simon,
Good point. I propose the following:
When a label is specified without -force, and that label begins with the interface name but is followed by something other than a colon, accept the label but emit a warning message indicating this label is incompatible with ifconfig and that later versions of the 'ip address' command may reject it. This message can also indicate that -force can be specified to explicitly indicate a label that is non ifconfig compatible is desired.
At some point in the future, the behavior could then be changed to reject such labels.
What do you think?
---
Joe
Quoted 25 lines
Quoted 12 lines
Hi Joe,
Quoted 5 lines · Joe Harvell
The ip addr command today rejects address labels that would break ifconfig. However, it allows some labels which still break it. Enhance enforcement to reject all known incompatible labels, and allow the existing -force option to allow someone to use a label even if it is not ifconfig compatible
I am concerned this will break existing users who are relying on setting labels that would now be rejected without using -force.
[snip]
Simon,
Good point. I propose the following:
When a label is specified without -force, and that label begins with the interface name but is followed by something other than a colon, accept the label but emit a warning message indicating this label is incompatible with ifconfig and that later versions of the 'ip address' command may reject it. This message can also indicate that -force can be specified to explicitly indicate a label that is non ifconfig compatible is desired.
Quoted 6 lines
At some point in the future, the behavior could then be changed to reject such labels.
What do you think?
---
Joe
Ok, I made the changes I propose above, and have pushed them to '[email protected]:jharvell/iproute2.git addr-label-noncompat' with a new signoff commit (303f46819883d4c808974629a6d3515102c5c0d0) that summarizes all the changes from master. But I'm not sure what I'm supposed to do with respect to the patch in patchwork to designate that I want the new code to be merged instead of before the change. Do I reject this patch request and submit another one? Do I send an email with the same subject as this one with the new patch against master?
Thanks.
---
Joe
Hi Joe,
Quoted 39 lines · Joe Harvell
Quoted 31 lines
Quoted 4 lines
Hi Joe,
On Sat, Mar 21, 2015 at 03:14:53PM -0500, Joe Harvell wrote:
Quoted 9 lines
Quoted 6 lines
The ip addr command today rejects address labels that would break ifconfig. However, it allows some labels which still break it. Enhance enforcement to reject all known incompatible labels, and allow the existing -force option to allow someone to use a label even if it is not
ifconfig compatibleI am concerned this will break existing users who are relying on setting labels that would now be rejected without using -force.
[snip]
Simon,
Good point. I propose the following:
When a label is specified without -force, and that label begins with the interface
name but is followed by something other than a colon, accept the label but emit
a warning message indicating this label is incompatible with ifconfig and that later
versions of the 'ip address' command may reject it. This message can also indicate
that -force can be specified to explicitly indicate a label that is non ifconfig compatible
is desired.Quoted 7 lines
At some point in the future, the behavior could then be changed to reject such labels.
What do you think?
---
Joe
Quoted 8 lines
Ok, I made the changes I propose above, and have pushed them to '[email protected]:jharvell/iproute2.git addr-label-noncompat' with a new signoff commit (
303f46819883d4c808974629a6d3515102c5c0d0) that summarizes all the changes from master. But I'm not sure what I'm supposed to do with respect to the patch in patchwork to designate that I want the new code to be merged instead of before the change. Do I reject this patch request and submit another one? Do I send an email with the same subject as this one with the new patch against master?
To some extent this is up to Stephen, who is the maintainer. But I expect the following should be close to the mark:
1. If you new patch has the same title as the previous patch then you can post it as [PATCH v2] and it should be fairly clear that it supersedes the previous version.
2. If you new patch has a different title then there could be a note in response to it noting that it has been superseded. In effect your previous email is such a note.
Hi Joe,
Quoted 25 lines · Joe Harvell
Quoted 11 lines
Hi Joe,
Quoted 5 lines · Joe Harvell
The ip addr command today rejects address labels that would break ifconfig. However, it allows some labels which still break it. Enhance enforcement to reject all known incompatible labels, and allow the existing -force option to allow someone to use a label even if it is not ifconfig compatible
I am concerned this will break existing users who are relying on setting labels that would now be rejected without using -force.
[snip]
Simon,
Good point. I propose the following:
When a label is specified without -force, and that label begins with the interface name but is followed by something other than a colon, accept the label but emit a warning message indicating this label is incompatible with ifconfig and that later versions of the 'ip address' command may reject it. This message can also indicate that -force can be specified to explicitly indicate a label that is non ifconfig compatible is desired.
Quoted 4 lines
At some point in the future, the behavior could then be changed to reject such labels.
What do you think?
That sounds entirely reasonable to me.