netdev - Re: [PATCH iproute2 v2] ip: drop 2-char command assumption

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 20 Apr 2021 21:49:46 -0700
From:   Tony Ambardar <tony.ambardar@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     David Ahern <dsahern@...il.com>,
        Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH iproute2 v2] ip: drop 2-char command assumption

On Tue, 20 Apr 2021 at 08:16, Stephen Hemminger
<stephen@...workplumber.org> wrote:
>
> On Tue, 20 Apr 2021 01:26:36 -0700
> Tony Ambardar <tony.ambardar@...il.com> wrote:
>
> > The 'ip' utility hardcodes the assumption of being a 2-char command, where
> > any follow-on characters are passed as an argument:
> >
> >   $ ./ip-full help
> >   Object "-full" is unknown, try "ip help".
> >
> > This confusing behaviour isn't seen with 'tc' for example, and was added in
> > a 2005 commit without documentation. It was noticed during testing of 'ip'
> > variants built/packaged with different feature sets (e.g. w/o BPF support).
> >
> > Mitigate the problem by redoing the command without the 2-char assumption
> > if the follow-on characters fail to parse as a valid command.
> >
> > Fixes: 351efcde4e62 ("Update header files to 2.6.14")
> > Signed-off-by: Tony Ambardar <Tony.Ambardar@...il.com>
> > ---
> > v2: (feedback from David Ahern)
> >   * work around problem but remain compatible with 2-char assumption
>
> I am ok with this, but if you change the name of command, you can expect some
> friction (and non support).
>

The renamed binaries are normally accessed via an 'ip' symlink managed
at package installation, so shouldn't be an issue. I only discovered
the problem while running regression tests on the the underlying
binaries, and thought to fix things.

> The original commit was inherited from the original integration of tarball's
> into BitKeeper. This "feature" was put in by Alexey Kuznetsov back in orignal 2.4
> time frame.

Thanks for the feedback and additional detail,
Tony