Red Hat Bugzilla – Bug 130768
xinetd sgi_fam GNOME tcpwrappers incompatibility
Last modified: 2007-11-30 17:07:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4)
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: FAIL: sgi_fam libwrap from=<no address>
xinetd: 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):
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
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
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:
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.