Description of problem: tcpmpatch fails, producing no output and an exit code of 1 when the specified hostname doesn't resolve (and hostname patterns are specified in hosts.{allow,deny}). Version-Release number of selected component (if applicable): tcp_wrappers-7.6-76.fc20.x86_64 How reproducible: Always for these hosts, I think. Steps to Reproduce: 1. try any of the following checks: $ /usr/sbin/tcpdmatch sshd 204.51.174.61.dial.wz.zj.dynamic.163data.com.cn $ /usr/sbin/tcpdmatch sshd 196.51.174.61.dial.wz.zj.dynamic.163data.com.cn $ /usr/sbin/tcpdmatch sshd 78.188.179.230.static.ttnet.com.tr $ /usr/sbin/tcpdmatch sshd 207.51.174.61.dial.wz.zj.dynamic.163data.com.cn $ /usr/sbin/tcpdmatch sshd 221.51.174.61.dial.wz.zj.dynamic.163data.com.cn $ /usr/sbin/tcpdmatch sshd foo.bar.cn Actual results: (no output, exit code=1) Expected results: Should give result as tcpd would. The only possible results are allow or deny, right? tcpd never fails, I don't think. Additional info: All but the last check suggested above are real hostnames taken from logs. I get the following warning often: warning: /etc/hosts.deny, line 15: can't verify hostname: gethostbyname(196.51.174.61.dial.wz.zj.dynamic.163data.com.cn) failed So, perhaps something like this would be appropriate from tcpdmatch: client: address (can't verify hostname) server: process sshd access: denied Here is my hosts.deny file: # # hosts.deny This file contains access rules which are used to # deny connections to network services that either use # the tcp_wrappers library or that have been # started through a tcp_wrappers-enabled xinetd. # # The rules in this file can also be set up in # /etc/hosts.allow with a 'deny' option instead. # # See 'man 5 hosts_options' and 'man 5 hosts_access' # for information on rule syntax. # See 'man tcpd' for information on tcp_wrappers # ALL: .cn, .com.cn sshd: UNKNOWN, PARANOID
I'd say it's an expected behaviour. tcpd gets a client hostname using gethostbyaddr() and then tries to check if can be resolved back to address so tcpd has at least source's ip address. While if you use a hostname without address, then tcpdmatch can't resolve it and has to terminate itself with error state and send warning to syslog. # host 78.188.179.230 230.179.188.78.in-addr.arpa domain name pointer 78.188.179.230.static.ttnet.com.tr. # host 78.188.179.230.static.ttnet.com.tr Host 78.188.179.230.static.ttnet.com.tr not found: 3(NXDOMAIN) # tcpdmatch sshd 78.188.179.230 client: address 78.188.179.230 server: process sshd access: denied # tcpdmatch sshd 78.188.179.230.static.ttnet.com.tr <log> Apr 12 00:05:53 hulk tcpdmatch: warning: 78.188.179.230.static.ttnet.com.tr: host not found # echo $? 1
Ah, okay, I understand what you are saying. Sure, sorry. Makes sense. I thought the tcpd code path was denying access based on the negative lookup, but you're saying the error occurse before the test. Ah, and it iterates over all addrs for that hostname? Okay, I didn't pick that up the first time through the manual. That's just a convenience feature for hostnames with mulitple addrs. The error is really in giving tcpdmatch a hostname that doesn't resolve, since that isn't how tcpd works in the first place. Exactly what you are saying. Okay. I don't like that the error message goes to log and nothing to STDERR. That's unexpected and not mentioned in the manpage. But, I understand what you are saying. Thank you for explaining.
I agree that there should go some error message also to stderr as it's primarily a command line tool. I'll try to add some in the next update.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.