Bug 16091 - sys-apps/tcp-wrappers ebuild does not respect USE=-ipv6
|
Bug#:
16091
|
Product: Gentoo Linux
|
Version: 1.4_rc2
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: aliz@gentoo.org
|
Reported By: farcepest@gmail.com
|
|
Component: Applications
|
|
|
URL:
|
|
Summary: sys-apps/tcp-wrappers ebuild does not respect USE=-ipv6
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2003-02-20 14:10 0000
|
Current tcp-wrappers builds (7.6-r4 and -r5 at least) always apply a patch for
ipv6 support. The USE flag for ipv6 is not checked to see whether ipv6 support
is actually desired.
This would not actually be a big problem, but the current patch breaks access
control when hostnames (or domains) are used and there is no ipv6 networking
support used. ipv4 network specifications work fine.
Example:
/etc/hosts.allow:
ALL: LOCAL
sshd: kenny.terry.uga.edu
/etc/hosts.deny:
ALL: ALL
# tcpdmatch -i /dev/null sshd kenny.terry.uga.edu
warning: sshd: no such process name in /dev/null
warning: host name/address mismatch: ::ffff:128.192.28.8 != kenny.terry.uga.edu
client: hostname paranoid
client: address ::ffff:128.192.28.8
server: process sshd
matched: /etc/hosts.deny line 1
access: denied
warning: host address 80c0:1c08:6b65:6e6e:792e:7465:7272:792e->name lookup failed
client: address 80c0:1c08:6b65:6e6e:792e:7465:7272:792e
server: process sshd
matched: /etc/hosts.deny line 1
access: denied
It appears that it checks ipv6 DNS records, and doesn't bother to fall back to
ipv4 if they aren't present. (Yes, the forward and reverse match in ipv4 in this
case.)
The ipv6 patch either needs to be updated to do the correct sequence of DNS
lookups, or there needs to be an option to avoid including it (the current
default USE flags would exclude the patch).
This is still a real bug that is easily duplicated. If you don't have ipv6
support, tcp-wrappers are BROKEN when using domain names in
/etc/hosts.{allow,deny}
This should be fixed in tcp-wrappers-7.6-r6. If not, please reopen this bug.
-r6 does seem to fix it, thanks. I hope this is marked stable soon.