Firewall

[Phil Knirsch]

On 12/07/2010 04:28 PM, Richard W.M. Jones wrote:
> On Tue, Dec 07, 2010 at 09:50:22AM +0000, Tim Waugh wrote:
>> On Mon, 2010-12-06 at 21:50 +0000, Richard W.M. Jones wrote:
>>> Still not seeing how /etc/iptables.d wouldn't work ...
>>
>> Here is how:
>>
>> When I ask CUPS for a list of network printers, it runs the backends
>> in /usr/lib/cups/backend.  One of those is /usr/lib/cups/backend/snmp,
>> which:
>>
>> a) binds to a local unprivileged UDP port
>> b) sends a broadcast SNMP request
>> c) listens for (unicast) responses to that request
>>
>> We don't hear any of those responses because they are not recognised as
>> "related" by the kernel.  The iptables rules drop them.
>>
>> If the CUPS snmp backend could say to "the firewall", "hey, please allow
>> responses on this port I've got for the next few seconds" -- which can
>> be controlled using PolicyKit -- then this network discovery would
>> finally work.
>>
>> There's no way to know the local UDP port in advance
>> so /etc/iptables.d-like systems all fail here.
>
> Does firewalld solve this?  Surely a solution to this is going to have
> to live in a stateful extension to iptables in the kernel, or a fix to
> the 'related' packets function?
>
> Rich.
>

I'm pretty sure it was one of the things that Thomas was looking into 
together with Tim as that has been one of the things that just didn't 
properly work out of the box for cups and printer discovery. I'm not 
exactly sure about how they planed to fix it though, i'd need to double 
check with him.

Thanks & regards, Phil

-- 
Philipp Knirsch              | Tel.:  +49-711-96437-470
Supervisor Core Services     | Fax.:  +49-711-96437-111
Red Hat GmbH                 | Email: Phil Knirsch <pknirsch at redhat.com>
Hauptstaetterstr. 58         | Web:   http://www.redhat.com/
D-70178 Stuttgart, Germany
Motd:  You're only jealous cos the little penguins are talking to me.