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]
Message-ID: <20210802172346.yj3ia7czg6o7kgn7@pali>
Date:   Mon, 2 Aug 2021 19:23:46 +0200
From:   Pali Rohár <pali@...nel.org>
To:     Guillaume Nault <gnault@...hat.com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: How to find out name or id of newly created interface

On Monday 02 August 2021 15:43:20 Guillaume Nault wrote:
> On Mon, Aug 02, 2021 at 12:58:25PM +0200, Pali Rohár wrote:
> > On Monday 02 August 2021 12:02:38 Guillaume Nault wrote:
> > > 
> > > So the proper solution is to implement NLM_F_ECHO support for
> > > RTM_NEWLINK messages (RTM_NEWROUTE is an example of netlink handler
> > > that supports NLM_F_ECHO, see rtmsg_fib()).
> > 
> > Do you know if there is some workaround / other solution which can be
> > used by userspace applications now? And also with stable kernels (which
> > obviously do not receive this new NLM_F_ECHO support for RTM_NEWLINK)?
> 
> I unfortunately can't think of any clean solution. It might be possible
> to create the new interface with attributes very unlikely to be used by
> external programs and retrieve the interface name and id by monitoring
> link creation messages (like 'ip monitor' does). But at this point it's
> probably easier to just set the interface name and retry with a
> different name every time it conflicted with an existing device.

"set interface name and retry" is what I'm using now... And looks like
it is the only stable solution for now.

I was already thinking about monitoring link creation messages... if
there is not some stable message ordering (e.g. order of response and
monitor message) but I have not deduced anything from the code.

> Maybe someone else could propose less hacky solutions, but I really
> can't think of anything else apart from implementing NLM_F_ECHO.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ