Bug 67792 - only_from=<hostname> is busted
only_from=<hostname> is busted
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.3
All Linux
medium Severity high
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-01 23:09 EDT by degraaf
Modified: 2007-04-18 12:43 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-07-01 23:09:16 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)

  None (edit)
Description degraaf 2002-07-01 23:09:12 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408

Description of problem:
The behaviour of xinetd seems to have changed between 7.2 and 7.3.
I can no longer use rsh from my machine with a dynamic IP to another
remote machine, despite having my machine's canonical name listed
in the remote's "only_from=datix.2y.net".

The current man page xinetd.conf(5) explains why this will not work.
(I no longer have access to a 7.2 machine to see if the man page
has changed.)  It says in paragraph d) under "only_from" that a host
name may be listed, eg, datix.2y.net.  When a connection is made to
xinetd, a *reverse* lookup is performed and the returned name is
compared to the listed name.

This can't possibly work for machines that have a dynamically assigned
IP and use services like dhs.org to translate a fixed domain name to
the current IP.
In such cases a forward lookup and a reverse lookup do not match.
Forward:        datix.2y.net  ->  65.83.169.133
Reverse:        65.83.169.133 ->  adsl-83-169-133.ard.bellsouth.net.

Not only is the IP assigned dynamically, but so is the bellsouth name,
so there is nothing I can put in the  only_from  list that would work.

Thus when my machine tries to run rsh on the remote machine, it
identifies itself (today) as 65.83.169.133 and inetd on the remote machine
does a reverse lookup and gets adsl-83-169-133.ard.bellsouth.net.
(today), which doesn't match the datix.2y.net in the
"only_from=datix.2y.net" statement, and the rsh command is denied.
I cannot see any way to allow a machine with a dynamically assigned IP
to use rsh on a remote machine with xinetd working this way.

The proper design, in my opinion, would be for xinetd to do a
*forward* DNS lookup on each canonical name in the only_from list
and match those IP's with the machine attempting to access xinetd
services.

Based on previous success in using rsh, the 7.2 version must have
worked this way.

Please revert xinetd to that previous useful behaviour.


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


How reproducible:
Always

Steps to Reproduce:
1.Configure "remote_machine" to allow rsh from datix.2y.net
Put into it's /etc/xinetd.d/rsh this line:
    only_from=datix.2y.net
2.  Ensure that machine datix.2y.net has a dynamically assigned IP
which is listed in the DNS tables provided by dhs.org, but that it's
reverse lookup gives a name assigned by the ISP.
3. On datix.2y.net try to execute
        rsh remote_machine  uname -a
and observe that the connection is refused:
        poll: protocol failure in circuit setup

	

Actual Results:  Any rsh command from datix.2y.net to remote_machine is refused.

With RH 7.2 these rsh commands succeeded.

Additional info:
Comment 1 Trond Eivind Glomsrxd 2002-07-03 11:57:31 EDT
I don't want to do Red Hat specific changes to the security policy of that app.
I'm monitoring the xinetd development list, I suggest you post that change
request there. If the author likes it, I'll add a patch.

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