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. */
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
