Bug 108583 - TCPwrappers block sgi_fam
TCPwrappers block sgi_fam
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xinetd (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
Brock Organ
:
: 113576 117529 128561 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-30 07:43 EST by David Jansen
Modified: 2014-08-31 19:25 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-17 06:08:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Contents on /etc/xinetd.d (2.42 KB, application/x-gzip)
2003-11-12 05:03 EST, David Jansen
no flags Details

  None (edit)
Description David Jansen 2003-10-30 07:43:39 EST
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.
Comment 1 Florian La Roche 2003-11-11 09:48:25 EST
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
Comment 2 David Jansen 2003-11-11 10:27:14 EST
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
Comment 3 Florian La Roche 2003-11-11 10:47:02 EST
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
Comment 4 Jay Fenlason 2003-11-11 11:44:37 EST
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 ? 
Comment 5 David Jansen 2003-11-12 05:03:43 EST
Created attachment 95921 [details]
Contents on /etc/xinetd.d
Comment 6 David Jansen 2003-11-12 05:07:47 EST
flags = NO_LIBWRAP does the trick, no messages in the logs, and login
is quick and painless. Thanks!
Comment 7 Simon Andrews 2003-11-27 11:33:53 EST
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.
Comment 8 Dave Rogers 2003-12-02 07:24:35 EST
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

Comment 9 Bruce Garlock 2004-01-14 13:18:12 EST
I am seeing this same problem on RH ES 3.0, however I did not have any
trouble logging in.
Comment 10 W. Michael Petullo 2004-04-11 09:44:52 EDT
The following bugs duplicate this report:

#117529
#114316
#113576
Comment 11 Robert Bartlett 2004-07-27 16:20:51 EDT
*** Bug 128561 has been marked as a duplicate of this bug. ***
Comment 12 W. Michael Petullo 2004-07-29 13:23:21 EDT
This seems to be made into a non-issue by the appearance of gamin.  Is
anyone else willing to confirm this?
Comment 13 Alexander Larsson 2004-08-17 06:08:57 EDT
Yes. This is gone with gamin.
Comment 14 Mark Eackloff 2004-08-21 21:05:31 EDT
With regard to Comments #4 & #6:  I believe that should be 
"flags = NOLIBWRAP"
Comment 15 Ignacio Vazquez-Abrams 2005-12-27 18:16:37 EST
*** Bug 113576 has been marked as a duplicate of this bug. ***
Comment 16 John Thacker 2006-10-28 13:07:39 EDT
*** Bug 117529 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.