From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 Description of problem: This is a problem which was reported for RH7 RH8 and FC1. It also has appeared in RHEL WS3. See buzilla reports 74696, 119918, 113576, 117529, and 108383. The use of ALL:ALL in hosts.deny sets up an unstable situation which may break sgi_fam and the GNOME DTMW, preventing X-windows login with GNOME. Another symptom is the repeated error message in messages: xinetd[23194]: FAIL: sgi_fam libwrap from=<no address> xinetd[4943]: START: sgi_fam pid=23195 from=<no address> A work around which seems to solve this problem is to add the following line to /etc/xinetd.d/sgi_fam flags = NOLIBWRAP Version-Release number of selected component (if applicable): xinetd-2.3.12-2.3E How reproducible: Always Steps to Reproduce: 1. add ALL:ALL to /etc/hosts deny 2. Login using the GNOME DTWM 3. Get Bluescreen, sgi_fam libwrappers error messages in /var/log/messages Additional info: This bug could cause many users to give up on using tcpwrappers to secure their machines. It has been fixed several times in the past, but seems to have resurfaced. The sgi_fam configuration fix seems to be the easiest to implement, and least likely to be accidently removed in the future. While the xinetd patch from RH7/8 has been lost again!
As the upstream xinetd co-maintainer, I agree with the flags = NOLIBWRAP. This has always been the suggested way to handle rpc or tcp-wait configurations. Xinetd losing the patch is OK. This in my opinion is a bug with the sgi_fam package. Even if xinetd gets the patch back in, having the flags option corrected would help if the patch was reverted again.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.