The Samba-Bugzilla – Bug 6485
force_lookup parameter to get_peer_name not effective
Last modified: 2009-12-07 04:43:51 UTC
If the hostname lookups config parameter is false (the default) then force_lookup will not cause get_peer_name to lookup and return the peer's DNS name. The reason is that if get_peer_name has previously been called with force_lookup set to false and hostname lookups is false, the IP address is cached instead of the name and subsequent calls always return the cached value even if force_lookup is true.
get_peer_name() is in util_sock.c at line 1815
The code would seem to imply that it was intended that force_lookup would cause a full DNS lookup no matter what the status of hostname lookups, but it doesn't work due to the cache feature.
What is the intended behaviour?
As it is, the result is that hostnames in allow hosts or deny hosts lists will not be matched unless hostname lookups is true. This is not documented in the hosts allow/deny section of the man page, though it is hinted at in the hostname lookups section.
I'm happy to provide code/words to do one of the following:
fix get_peer_name to honour the force_lookup flag (would need some input on how the cache works)
add some words to hosts allow/deny manual section saying that hostnames will never be matched if hostname lookups is false
add some words to the %M section of the manual page saying that IP addresses will appear unless hostname lookups is true.
We've hit this problem when upgrading from 3.0.28a to 3.2.15: In the 3.0 version, hostnames in hosts allow/deny were correctly matched even without "hostname lookups = yes". In 3.2, we get
[2009/10/13 09:56:02, 3] lib/access.c:check_access(396)
check_access: hostnames in host allow/deny list.
[2009/10/13 09:56:02, 0] lib/access.c:check_access(410)
Denied connection from 126.96.36.199 (188.8.131.52)
This indicates that get_peer_name() returned an IP address instead of a hostname even with parameter "force_lookup" set as true. Reverse lookup of "184.108.40.206" works fine on the Samba server.
For us using "hosts allow" only, this just implies a regression from 3.0 to 3.2. However, considering configurations like "hosts deny = <hostname>", the issue amounts to a security problem, I believe.