netdev - Re: [PATCH net-next] sockopt: Introduce the SO

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: <50870F91.8000801@hp.com>
Date:	Tue, 23 Oct 2012 17:43:45 -0400
From:	Brian Haley <brian.haley@...com>
To:	David Miller <davem@...emloft.net>
CC:	xemul@...allels.com, bhutchings@...arflare.com,
	eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] sockopt: Introduce the SO_BINDTOIFINDEX

On 10/23/2012 01:36 PM, David Miller wrote:
> 
> This is really a huge ball of confusion.
> 
> The user asks for a device to bind to, and they want the device which
> had a particular name at the time of the call.
> 
> If you allow setting this via ifindex, the issues and races are the
> same whether the name-->ifindex translation is done before the
> sockopt() call or during it.

Yes, there are race conditions in the socket APIs, even IP addresses can go away
right before a bind() call.

> Furthermore both the name and the ifindex can change (that latter
> via module unload/load).
> 
> If you want me to consider these changes seriously, talk less about
> obtuse issues like symmetry and more about what problems it actually
> solves.  As far as I can tell, all the same real issues still exist
> even if we had this new interface.

Noone's complained about not having this getsockopt() for over 7+ years, so in
that sense I'm not sure what problem it solved adding it.

> In fact, I wouldn't mind if a getsockopt() on SO_BINDTODEVICE returned
> BOTH the name and the ifindex in a special structure.  Then you could
> actually construct a more foolproof mechanism on the user side to try
> various ways to get the same device bound to during restart.

There is no fool-proof way to do any of this since we can agree device names and
indexes can change.  But people aren't typically running daemons listening on
interfaces that are constantly changing like taps or tunnels, instead it's on
eth1 so they can run a private DHCP server.

> Symmetry is over-rated.

If any of the other SO_* options didn't set and get using the same structure I'd
agree with you, but I can't find any that do.

-Brian

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html