This service will be undergoing non-disruptive maintenance at 07:20 UTC, 2018-12-14. It is expected to last approximately 30 minutes
Bug 108583 - TCPwrappers block sgi_fam
Summary: TCPwrappers block sgi_fam
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xinetd (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
: 113576 117529 128561 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-10-30 12:43 UTC by David Jansen
Modified: 2014-08-31 23:25 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-17 10:08:57 UTC
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 10:03 UTC, David Jansen
no flags Details

Description David Jansen 2003-10-30 12:43:39 UTC
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 14:48:25 UTC
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 15:27:14 UTC
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 15:47:02 UTC
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 16:44:37 UTC
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 10:03:43 UTC
Created attachment 95921 [details]
Contents on /etc/xinetd.d

Comment 6 David Jansen 2003-11-12 10:07:47 UTC
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 16:33:53 UTC
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 12:24:35 UTC
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 18:18:12 UTC
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 13:44:52 UTC
The following bugs duplicate this report:

#117529
#114316
#113576

Comment 11 Robert Bartlett 2004-07-27 20:20:51 UTC
*** Bug 128561 has been marked as a duplicate of this bug. ***

Comment 12 W. Michael Petullo 2004-07-29 17:23:21 UTC
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 10:08:57 UTC
Yes. This is gone with gamin.

Comment 14 Mark Eackloff 2004-08-22 01:05:31 UTC
With regard to Comments #4 & #6:  I believe that should be 
"flags = NOLIBWRAP"

Comment 15 Ignacio Vazquez-Abrams 2005-12-27 23:16:37 UTC
*** Bug 113576 has been marked as a duplicate of this bug. ***

Comment 16 John Thacker 2006-10-28 17:07:39 UTC
*** 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.