Hide Forgot
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 possible again. Version-Release number of selected component (if applicable): tcp_wrappers-7.6-34.as21.1 fam-2.6.8-12 How reproducible: Always 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 Additional info: Contents of /etc/hosts.allow : ALL: LOCAL 192.168. sshd: ALL Contents of /etc/hosts.deny: ALL: ALL 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? greetings, Florian La Roche
Yes, it's xinetd: Nov 11 16:25:53 eendracht xinetd[23526]: warning: can't get client address: Transport endpoint is not connected Nov 11 16:25:53 eendracht xinetd[23526]: 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 is gone. David Jansen
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 fam/whatever components. 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 /etc/xinetd.d/sgi_fam ?
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 which worked. 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[1765]: Starting reconfiguration Dec 2 06:17:50 phoebe xinetd[1765]: Bad service flag: NO_LIBWRAP [file=/etc/xinetd.d/sgi_fam] [line=16] Dec 2 06:17:50 phoebe xinetd[1765]: Error parsing attribute flags - DISABLING SERVICE [file=/etc/xinetd.d/sgi_fam] [line=16] Dec 2 06:17:50 phoebe xinetd[1765]: 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: #117529 #114316 #113576
*** 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. ***