[PATCH 0/1] lib: Align naming rules with the kernel

[PATCH 0/1] lib: Align naming rules with the kernel

[Christoph Anton Mitterer]

Hey.

Seems the check rules in iproute2 have gotten out of sync with those of the
kernel. This patch brings them up-to-date.

It shall be noted, that these changes would also affect those for alnames (like
before, just without enforcing the maximum length, which AFAIU was the main (or
even whole?) point of altnames[0]).


I made a small test and compiled iproute2 with its `check_altifname()` simply
always returning true.
Turnes out, that the kernel seems to accept any name (i.e. including whitespace
and `/`) and I didn’t find any check functions for altnames in the kernel
either (okay I didn’t look that hard ^^).

Not sure, but maybe altnames should really be allowed to contain anything?
If so, we’d of course need to change this patch.
OTOH, e.g. systemd already assumes that certain characters aren’t allowed in
interface names (see `Name=` in systemd.link(5)) and e.g. `nmcli` uses `:` to
separate fields in its machine readable output.

But then again, the kernel should perhaps check altnames?


Cheers,
Chris.

[0] https://lore.kernel.org/netdev/20190719110029.29466-1-jiri@resnulli.us/

[PATCH 1/1] lib: Align naming rules with the kernel

[Christoph Anton Mitterer]

This aligns the naming rules with those of the kernel as set in the
`dev_valid_name()`-function in `net/core/dev.c`.

It also affects the validity of altnames.

Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
---
 lib/utils.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/utils.c b/lib/utils.c
index 0719281a..e4e5f337 100644
--- a/lib/utils.c
+++ b/lib/utils.c
@@ -851,8 +851,10 @@ static int __check_ifname(const char *name)
 {
 	if (*name == '\0')
 		return -1;
+	if (!strcmp(name, ".") || !strcmp(name, ".."))
+		return -1;
 	while (*name) {
-		if (*name == '/' || isspace(*name))
+		if (*name == '/' || *name == ':' || isspace(*name))
 			return -1;
 		++name;
 	}
-- 
2.51.0

Re: [PATCH 1/1] lib: Align naming rules with the kernel

[Stephen Hemminger]

On Fri, 12 Dec 2025 05:18:13 +0100
Christoph Anton Mitterer <mail@christoph.anton.mitterer.name> wrote:

> This aligns the naming rules with those of the kernel as set in the
> `dev_valid_name()`-function in `net/core/dev.c`.
> 
> It also affects the validity of altnames.
> 
> Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
> ---
>  lib/utils.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/utils.c b/lib/utils.c
> index 0719281a..e4e5f337 100644
> --- a/lib/utils.c
> +++ b/lib/utils.c
> @@ -851,8 +851,10 @@ static int __check_ifname(const char *name)
>  {
>  	if (*name == '\0')
>  		return -1;
> +	if (!strcmp(name, ".") || !strcmp(name, ".."))
> +		return -1;
>  	while (*name) {
> -		if (*name == '/' || isspace(*name))
> +		if (*name == '/' || *name == ':' || isspace(*name))

Do you check that this didn't break the legacy ifalias stuff?

Re: [PATCH 0/1] lib: Align naming rules with the kernel

[Stephen Hemminger]

On Fri, 12 Dec 2025 05:18:12 +0100
Christoph Anton Mitterer <mail@christoph.anton.mitterer.name> wrote:

> I made a small test and compiled iproute2 with its `check_altifname()` simply
> always returning true.
> Turnes out, that the kernel seems to accept any name (i.e. including whitespace
> and `/`) and I didn’t find any check functions for altnames in the kernel
> either (okay I didn’t look that hard ^^).
> 
> Not sure, but maybe altnames should really be allowed to contain anything?
> If so, we’d of course need to change this patch.
> OTOH, e.g. systemd already assumes that certain characters aren’t allowed in
> interface names (see `Name=` in systemd.link(5)) and e.g. `nmcli` uses `:` to
> separate fields in its machine readable output.
> 
> But then again, the kernel should perhaps check altnames?

The restrictions in the kernel are because interface names also show up in sysfs
which can't allow invalid filenames. The altnames don't show up in sysfs now.

Re: [PATCH 1/1] lib: Align naming rules with the kernel

[Christoph Anton Mitterer]

On Fri, 2025-12-12 at 13:55 +0900, Stephen Hemminger wrote:
> > -		if (*name == '/' || isspace(*name))
> > +		if (*name == '/' || *name == ':' ||
> > isspace(*name))
> 
> Do you check that this didn't break the legacy ifalias stuff?

No, I did not.

Where is __check_ifname() or any of its callers used by it?

Thanks :-)
Chris.

Re: [PATCH 0/1] lib: Align naming rules with the kernel

[Christoph Anton Mitterer]

On Sat, 2025-12-13 at 09:20 +0900, Stephen Hemminger wrote:
> I don't there would be a problem altnames are intended to be more
> flexible.
> And it would make sense since Cisco standard is something like
> Gigabit/0/0
> for names.  Why not remove check and see what breaks?

Which exactly? The one for altnames altogether?

That seems a bit risky, TBH, given that tools might output these names
and use the currently forbidden chars as separators, assuming they’d be
safe to use so.
Especially since `__check_ifname()` via `check_altifname()` also
forbids spaces and newlines.

OTOH, the kernel, AFAIU, allows it already so merely forbidding it in
iproute2 is anyway only a weak protection.

I’ve looked at few tools whom I know output the altnames:
# networkctl status virbr1 
● 14: virbr1
                   Link File: /usr/lib/systemd/network/99-default.link
                Network File: n/a
                       State: no-carrier (unmanaged)
                Online state: unknown
                        Type: bridge
                        Kind: bridge
                      Driver: bridge
           Alternative Names: foo
                              bar
                              foo bar
                              foo.bar
                              foo:bar
                              foobar
            Hardware Address: 52:54:00:3a:2d:43
                         MTU: 1500 (min: 68, max: 65535)
                       QDisc: noqueue
IPv6 Address Generation Mode: none
               Forward Delay: 2s
                  Hello Time: 2s
                     Max Age: 20s
                 Ageing Time: 5min
                    Priority: 32768
                         STP: yes
      Multicast IGMP Version: 2
                        Cost: 2000
                 FDB Learned: 0
             FDB Max Learned: 0
                  Port State: disabled
    Number of Queues (Tx/Rx): 1/1
            Auto negotiation: no

(here `foo\nbar` was one altname with newline... which I set via a
patched `ip`.

# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
14: virbr1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether 52:54:00:3a:2d:43 brd ff:ff:ff:ff:ff:ff
    altname foo:bar
    altname foo.bar
    altname foo bar
    altname foobar
    altname foo
bar

networkctl has its --json mode, so parsing its regular output is anyway
obviously unsafe.

ip’s output however might be parsed by people... and in particular
allowing \n might break that (but allowing other whitespace might, too.

What do you think?

And any clue where these checks would be used for the ifalias thingy
you’ve mentioned?


Cheers,
Chris.