netdev - Re: PATCH: Multicast: Filter multicast traffic per socket mc

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: <OF0F292ED0.17C084A6-ON8825759A.00718BFC-8825759A.00730FD8@us.ibm.com>
Date:	Thu, 16 Apr 2009 13:56:49 -0700
From:	David Stevens <dlstevens@...ibm.com>
To:	Christoph Lameter <cl@...ux.com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org, Neil Horman <nhorman@...driver.com>,
	vladislav.yasevich@...com
Subject: Re: PATCH: Multicast: Filter multicast traffic per socket mc_list

> Well guess then we need the global proc setting after all. With the
> current misbehavior as a default applications need to be rebuilt and

        The current behavior, as either your or Vlad's RFC quotes pointed
out as easily as the history to go with it, is exactly the expected 
behavior
for decades. I think it is not misbehavior so much as your misconception,
though a common one.

> source code that is running on multiple OSes now would have to 
customized
> to special case for Linux.

        No, actually. If you write it for the current behavior, it'll work
fine on an OS like Solaris that has departed from the original socket
behavior. If you're sloppy and don't handle unexpected traffic, it'll be
wrong on both-- you just won't know it until someone runs something with
the same port and multicast address on your network and wrecks your app.

> So add a global proc setting to determine the initial setting of 
IP_MULTICAST_ALL?

        This breaks unknown existing applications that are correctly
written. I think it's clearly wrong to change the behavior of someone
else's socket to match your idea of how it should've been done 25 years
too late. An option that enables new behavior for your own socket, which
must be a new app, is fine. Adding a socket option as part of a port
is no great hurdle, and I'm guessing you aren't trying to run a Solaris
binary on Linux. So what's the problem?

                                                                +-DLS

--
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