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]

Date:	Thu, 16 Apr 2009 16:30:39 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	David Stevens <dlstevens@...ibm.com>
Cc:	Vlad Yasevich <vladislav.yasevich@...com>,
	Christoph Lameter <cl@...ux.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	netdev-owner@...r.kernel.org, Neil Horman <nhorman@...driver.com>
Subject: Re: PATCH: Multicast: Filter multicast traffic per socket mc_list

On Thu, 16 Apr 2009 15:22:49 -0700
David Stevens <dlstevens@...ibm.com> wrote:

> Vlad Yasevich wrote on 04/16/2009 02:19:14 PM:
> 
> > What seems to be happening though, is that there is an expectation that
> > this behavior would change with advent of IGMPv3, which adds the 
> additional
> > filtering text.  Now, we could point out that there is no normative text
> > that requires this filtering on groups, only on sources, but the 
> expectation
> > is still there.
> 
>         I have no such expectation. :-) The additional filters are 
> (already)
> applied per-socket, but existing apps not using source filters behave as
> they did before IGMPv3. That's what I'd expect.
>         The RFC you quoted for SSM applies to only the SSM address space,
> mentions this behavior explicitly as the norm for outside of that space,
> and Linux doesn't support that RFC. If it did, it would include an
> address range check as part of it.
> 
> > I wonder how BSD and Solaris got away with it?  They both filter on 
> multicast
> > groups and source addresses.  This is not meant as rhetorical or 
> provocative,
> > just genuinely wondering.
> 
>         I think in practice, it doesn't come up much. That's why people
> seem so surprised to learn it works this way, and not the way they
> thought it did after using it, sometimes for years. But the documentation
> doesn't say a join limits what you receive on a socket, or that it
> has to be the same socket you're doing I/O on; people simply assume it.
> 
>                                                                 +-DLS

You could always use packet/socket filter to keep the packets from
coming out to user space.
--
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