On 26/10/12 15:02, Simon Kelley wrote: > On 24/10/12 18:59, Dan Williams wrote: >
> This is a good example of the pitfalls: it possible to specify the local > address and port used to contact a server, thus: > > server=192.168.0.1@192.168.100.1#800 > > which ensures that queries sent to 192.168.0.1 have a source address > 192.168.100.1 port 800. 192.168.100.1 has to be an address in local > machine obviously. > > Clearly adding a new server spec of this type has the potential to fail: > 192.168.100.1 might not exist on a local interface, or something else > may be listening on port 800. There's an additional problem: if the port > is <1024, then the configuration will work fine when dnsmasq first > starts and the bind() calls are done as root, but fail if the > configuration is re-read, since the bind() calls then are done as an > unprivileged user. > > Just to add to the noise, on some platforms (Linux, Solaris) bind() > won't fail, because dnsmasq retains the CAP_NET_ADMIN capability. Other > platforms don't allow this, so it breaks. > > It would be possible to add the equivalent of dhcp-optsfile and > dhcp-hostsfile, which get re-read on SIGHUP but source-addresses should > not be supported in those. They should probably not be provided in the > new DBus call either, for the same reason. > The above isn't quite accurate: s/CAP_NET_ADMIN/CAP_NET_BIND_SERVICE/ for a start, but the broader point still applies. Simon. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
