Red Hat Bugzilla – Bug 108583
TCPwrappers block sgi_fam
Last modified: 2014-08-31 19:25:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007
Description of problem:
I have tcp wrappers configured to allow all services locally and from the local
subnet, and block all but ssh from anywhere else.
Now, after I made this change, I cannot login using gnome (root, or normal user
alike), but twm, failsafe and KDE still work.
In /var/log/messages I saw lots of lines like this:
warning: can't get client address: Transport endpoint is not connected
libwrap refused connection to sgi_fam (libwrap=fam) from <no address>
so despite the fact that all services should be allowed to connect locally, fam
is blocked, since either fam doesn't present its source address, or libwrap
fails to see that address.
As a workaround, I added 'fam: ALL' to /etc/hosts.allow and then logging in is
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. configure tcp_wrappers, allowing all connections from the local net and
localhost, but denying everything else
2. try to log in using the Gnome desktop
Actual Results: The Gnome splash screen appears, and after that, nothing
happens on screen, but the disk is awfully busy, and the logs get lots of
messages as quoted above.
Expected Results: A nice. beautiful Gnome desktop
Contents of /etc/hosts.allow :
ALL: LOCAL 192.168.
Contents of /etc/hosts.deny:
Note: there was no difference when listsing localhost, 127.0.0.1 or any other
reference to the local system.
Can you tell me which application is sending out the warning messages
in /var/log/messages? Are you sure you have properly restarted the
servers after doing the config change to the above settings?
Florian La Roche
Yes, it's xinetd:
Nov 11 16:25:53 eendracht xinetd: warning: can't get client
address: Transport endpoint is not connected
Nov 11 16:25:53 eendracht xinetd: libwrap refused connection to
sgi_fam (libwrap=fam) from <no address>
It's totally reproducible (even after reinstalling FC1. As soon as I
remove the fam: ALL line in /etc/hosts.allow the problem is back on
the next login, and as soon as the line is added back in, the problem
Moving to xinetd as that rpm does libwrap handling with its own
source code and there might be a bug with that. I'll add me to CC:
in case this bug needs to be flipped back to tcp_wrappers or
Thanks for this bug-report,
Florian La Roche
Can you attach a tar file of your /etc/xinetd.d directory to this bug report?
Also, what happens if you add "flags = NO_LIBWRAP" to
Created attachment 95921 [details]
Contents on /etc/xinetd.d
flags = NO_LIBWRAP does the trick, no messages in the logs, and login
is quick and painless. Thanks!
Have just been bitten by this one as well, and also found the same fix
Whilst looking into the problem I can across bug #74696 which
describes the same thing under RH8, and which seems to have been fixed
with a patch to xinetd.
In both cases the problem seems to be that although sgi_fam is bound
to 127.0.0.1, the address is not correctly passed to libwrap so any
filters in place do not work. The work round is OK for now, but I'd
rather be able to put appropriate access controls onto sgi_fam.
When I added this fix to /etc/xinetd.d/sgi_fam and restart xinetd I
get the following error logged to /var/log/messages:
Dec 2 06:17:50 phoebe xinetd: Starting reconfiguration
Dec 2 06:17:50 phoebe xinetd: Bad service flag: NO_LIBWRAP
Dec 2 06:17:50 phoebe xinetd: Error parsing attribute flags -
DISABLING SERVICE [file=/etc/xinetd.d/sgi_fam] [line=16]
Dec 2 06:17:50 phoebe xinetd: service sgi_fam deactivated
I am seeing this same problem on RH ES 3.0, however I did not have any
trouble logging in.
The following bugs duplicate this report:
*** Bug 128561 has been marked as a duplicate of this bug. ***
This seems to be made into a non-issue by the appearance of gamin. Is
anyone else willing to confirm this?
Yes. This is gone with gamin.
With regard to Comments #4 & #6: I believe that should be
"flags = NOLIBWRAP"
*** Bug 113576 has been marked as a duplicate of this bug. ***
*** Bug 117529 has been marked as a duplicate of this bug. ***