On Fri, Mar 22, 2013 at 01:58:50PM -0400, Stefan Berger wrote: > On 03/22/2013 01:49 PM, Daniel P. Berrange wrote: > >On Fri, Mar 22, 2013 at 08:26:59AM -0400, Stefan Berger wrote: > >>Linux netfilter at some point inverted the meaning of the '--ctdir reply' > >>and newer netfilter implementations now expect '--ctdir original' > >>instead and vice-versa. > >>We probe for this netfilter change via a UDP message over loopback and 3 > >>filtering rules applied to INPUT. If the sent byte arrives, the newer > >>netfilter implementation has been detected. > >I think this is really very hackish. If this test capability goes > >wrong for any reason, then we're going to silently setting up > >incorrect rules, which would be a security flaw. I think we need > >a more robust detection system for this. > > What method do you suggest? We cannot look in the kernel afaik so we > have to probe it. We have to setup some rules to make this work and > the tighter the rules are the better, so they don't interfer with > anything else. Then of course we need to send 'something' so we can > detect whether this is an old or a new system. We could of course > send once with the rules with '--ctdir ORIGINAL' and then do a 2nd > test with '--ctdir REPLY' to make sure that it works at all. But > what would we do if we detected that it doesn't work in either one > of the cases? Terminate? The assumption of the code was that we have > a working loopback device. When was the change in semantics made to iptables ? Is this considered a critical bug by iptables maintainers, if so then we could just use the correct syntax unconditionally, and let distro vendors fix their iptables binaries to work correctly, instead of trying to workaround the brokeness. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list