Bug 74696 - Broken tcp_wrappers support
Summary: Broken tcp_wrappers support
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xinetd
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact:
URL:
Whiteboard:
: 75055 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-09-30 23:03 UTC by James Antill
Modified: 2007-04-18 16:46 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-12-02 20:37:25 UTC
Embargoed:


Attachments (Terms of Use)
Replacement for patch0 in xinetd 2.3.7-3 (1.21 KB, patch)
2002-10-02 08:27 UTC, Alexander Larsson
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2002:196 0 normal SHIPPED_LIVE : Updated xinetd packages fix denial of service vulnerability 2002-09-06 04:00:00 UTC

Description James Antill 2002-09-30 23:03:23 UTC
Description of Problem:
 SGI fam will not allow any connections, and I presume it has something to do
with these messages in /var/log/messages...

Sep 30 18:31:27 code xinetd[2684]: warning: can't get client address: Transport
endpoint is not connected
Sep 30 18:31:27 code xinetd[2684]: libwrap refused connection to sgi_fam from
<no address>
Sep 30 18:31:27 code xinetd[2685]: warning: can't get client address: Transport
endpoint is not connected
Sep 30 18:31:27 code xinetd[2685]: libwrap refused connection to sgi_fam from
<no address>
Sep 30 18:31:27 code xinetd[2686]: warning: can't get client address: Transport
endpoint is not connected
Sep 30 18:31:27 code xinetd[2686]: libwrap refused connection to sgi_fam from
<no address>
Sep 30 18:31:27 code xinetd[693]: Deactivating service sgi_fam due to excessive
incoming connections.  Restarting in 30 seconds.

...so it looks like tcp_wrappers aren't being passed the correct IP address.

Version-Release number of selected component (if applicable):
fam-2.6.8-4

How Reproducible:
 Always.

Steps to Reproduce:
1. Have secure machine, via. /etc/hosts.*
2. Try and run nautilus.
3. Observe messages about fam being broken.

Actual Results:


Expected Results:


Additional Information:

Comment 1 Ali-Reza Anghaie 2002-10-01 12:37:15 UTC
Did you add 127.0.0.1 to the hosts.allow? -Ali

Comment 2 James Antill 2002-10-01 19:18:57 UTC
 Yes, I'd also tried...

sgi_fam: ALL

...in /etc/hosts.allow ... neither do anything useful.

Comment 3 Ali-Reza Anghaie 2002-10-01 19:41:25 UTC
For some reason I can't replicate this. Perhaps I've got a mutant package set 
here. I'm gonna try with a really fresh Psyche. -Ali

Comment 4 Alexander Larsson 2002-10-01 20:57:11 UTC
I get this on my 8.0 upgrade. Haven't looked into it yet.


Comment 5 Alexander Larsson 2002-10-02 07:39:07 UTC
On my fresh everthing 8.0 i don't get this. Strange.


Comment 6 Alexander Larsson 2002-10-02 07:56:02 UTC
Oh. It didn't have deny all:all.
I suspect xinetd here. It tends to break fam all the time...

Comment 7 Alexander Larsson 2002-10-02 08:26:14 UTC
Correct. Someone disabled the xinetd patch that make stream+wait services work.
It looks like it failed to apply due to whitespace changes. I'm attaching an
updated version of the patch.


Comment 8 Alexander Larsson 2002-10-02 08:27:34 UTC
Created attachment 78044 [details]
Replacement for patch0 in xinetd 2.3.7-3

Comment 9 Alexander Larsson 2002-10-02 08:30:13 UTC
Eh. make that 2.3.7-2

Comment 10 Han-Wen Nienhuys 2002-10-03 22:31:30 UTC
No go,

the patch doesn't work for me. Gnome-session beautifully hangs upon login, until
I kill xinetd.


Comment 11 Alexander Larsson 2002-10-04 16:21:06 UTC
After installing the patched xinetd, did you restart portmap and xinetd?


Comment 12 Alexander Larsson 2002-10-04 16:21:18 UTC
*** Bug 75055 has been marked as a duplicate of this bug. ***

Comment 13 Alexander Larsson 2002-10-04 16:22:35 UTC
and are you sure you applied the patch, patch0 is disbled (commented out) in the
current xinetd specfile.

Comment 14 Bob Arendt 2002-10-07 03:19:42 UTC
Bug 75055 was marked as a duplicate of this and closed, but I don't
think it's a duplicate.  I have FAM running, but nautilus and gnome-panel
stall unless I kill fam.  Then gnome-panel continues.  It appears to be
a race condition, down in the gnome-vfs - fam interaction.  I posted
some debug output to bug 75055 relevant to this.

I'm currently running with fam disabled.  nautilus and gnome-panel
squawk that FAMOpen fails, but I assume vfs falls back to a polling
method to determine relevant directory and file events.  Now they seem
to run fine (though they'd probably work better if I could use fam).

Comment 15 diego.santacruz 2002-10-09 11:59:05 UTC
I have also the same problem on a fresh 8.0 install: xinetd refuses to start fam
with same messages as reported initially and that blocks the gnome login. I have
ALL: ALL in /etc/hosts.deny and ALL: 127.0.0.1 in /etc/hosts.allow.

As a temporary workaround I added

flags        = NOLIBWRAP

in /etc/xinetd.d/sgi_fam. Since fam is only bound to 127.0.0.1 this should not
hinder security. Of course this is just a workaround to get the thing working
and not a proper fix.

Comment 16 Alexander Larsson 2002-10-09 13:46:21 UTC
I believe an xinetd errata is planned.


Comment 17 Need Real Name 2002-10-20 01:38:59 UTC
I have the same problem on a fresh install of RedHat 8.0.  I receive a single
"can't get client address ... Transport endpoint ..." error message, but GNOME
continues to run.

I tried updating to the latest xinetd (2.3.9) - this did *not* eliminate the error.

Applying the patch attached to this thread *did* eliminate the error message.

Seems like the patch simply defeats libwrap.  Is the patch more secure than
putting flags = NOLIBWRAP in the sgi_fam xinetd config file ?

Comment 18 Alexander Larsson 2002-10-21 08:57:13 UTC
There really is no difference, fam is a stream+wait protocol. This means the
launched app gets the socket that you accept() on, which is not connected to the
endpoint. libwrap can never do anything useful on that socket.

This is what is causing the "endpoint not connected" errors.

our fam binds only to 127.0.0.1, so it's not a security issue.

Comment 19 Andrew Gormanly 2002-11-11 23:19:38 UTC
I had the same problem on a fresh 8.0 install, and the 'flags = NOLIBWRAP'
workaround solved it for me.

This totally killed X logins on an old K6-2 box w/ 192MB - I got the Red Hat
splash screen but no icons below, as nothing got around to starting up.

Could I suggest putting out some respin isos once the fix is in?  This could be
a showstopper for a newbie...

Comment 20 Bill Nottingham 2002-11-19 16:59:21 UTC
Patch added in 2.3.7-5.

Comment 21 Bill Nottingham 2002-12-02 20:37:25 UTC
An errata has been issued which should help the problem described in this bug report. 
This report is therefore being closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, please follow the link below. You may reopen 
this bug report if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2002-196.html


Comment 22 Jose Luis Nuñez 2004-03-04 22:59:05 UTC
Hi, this error has been suffering by since I moved from Red Hat 9.0 to
Fedora-1 a couple of weeks ago.

I have read this bugtrack but I still don't know how to fix it. I'm
affraid that the patch given in this bug list is for an old version of
xinetd, and ist not valid for me, in fact I'm using xinetd-2.3.12-4.10.0.

I don't know if it is relevant or not, but KDE is running ok in the
same box.

May I open a new bug?

Thanx in advance

Jose Luis Nuñez

Comment 23 Greg Ennis 2004-04-03 04:58:36 UTC
Everyone,

I am having the same problem as Jose on a new FC1 installation using 
xinetd xinetd Version 2.3.12 libwrap loadav.  My message files and 
secure files are being filled by:

xinetd[1077]: START: sgi_fam pid=5915 from=<no address>
xinetd[5915]: FAIL: sgi_fam libwrap from=<no address>

My gnome interface is also not working but KDE works fine.

Since I did not get a solution i opened a new bug report #119918 

Greg Ennis




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