Skip to contentSkip to conversation

iproute2: enhance addr label validation

PATCH In review Joe Harvell 2 participants 6 messages Mar 21, 2015 – Mar 25, 2015

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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
index 9151c4f..e8a5467 100644
@@ -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
index da16b15..78b0197 100644
@@ -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
index 99a6ab5..be027c6 100644
@@ -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
index 016e8c6..f58241f 100644
@@ -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
#1 lore raw

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 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
index 9151c4f..e8a5467 100644
@@ -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
index da16b15..78b0197 100644
@@ -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
index 99a6ab5..be027c6 100644
@@ -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
index 016e8c6..f58241f 100644
@@ -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

#2 lore raw
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

#3 lore raw
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

#4 lore raw

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 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 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.

#5 lore raw
In reply to Joe Harvell

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.