Firewall

[Tim Waugh]

On Tue, 2010-12-07 at 11:18 -0500, Matthew Miller wrote:
> Is there a compelling reason for this not to be:
> 
> - cups snmp backend says to "the firewall", "hey, please allow
>   responses on this port I've got"
> - cups snmp backend listens for responses until timeout
> - cups snmp backend says to "the firewall", "hey, I'm done now. thanks!"
> 
> That seems more helpful than "a few seconds" anyway. And worst case is that
> the snmp backend crashes or otherwise forgets to remove its rule, which
> shouldn't be terribly severe since then it won't be listening, either. Some
> other point the the cups startup/stop process could make sure any such
> leftover rules are cleared just to be sure.

Well, it could be done that way.  The reason I didn't suggest that
originally was that CUPS has to kill backends if they take too long, so
it would seem quite likely that stale rules would get left around in
some instances if they required explicit revocation.

In the worst case you have a random unprivileged UDP port open --
there's nothing to associate it with SNMP, or the CUPS snmp backend.
The backend won't be listening on it, but some other process may well
choose that port later on.

> I have no problem with the mechanism for talking to the firewall being some
> PolicyKit-enabled helper program. I just don't see a strong argument for it
> being a daemon.

With D-Bus object activation, maybe it doesn't need to be running all
the time (e.g. as with the current system-config-firewall D-Bus
service)?  I'm not sure as I haven't seen the prototype yet.

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101209/abb56a3d/attachment.bin