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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0538367890210f8bbaf70ed6bd1cea3491463b35.camel@christoph.anton.mitterer.name>
Date: Sat, 13 Dec 2025 02:48:28 +0100
From: Christoph Anton Mitterer <mail@...istoph.anton.mitterer.name>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH 0/1] lib: Align naming rules with the kernel

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.