Bug 23753 - xinetd fails to set REMOTE_HOST environment
Summary: xinetd fails to set REMOTE_HOST environment
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xinetd   
(Show other bugs)
Version: 7.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-01-10 22:50 UTC by jwitford
Modified: 2007-04-18 16:30 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-06 23:16:21 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)
xinetd patch for REMOTE_HOST environment variable (2.71 KB, patch)
2001-01-10 22:51 UTC, jwitford
no flags Details | Diff
xinetd patch for REMOTE_HOST environment variable (2.68 KB, patch)
2001-01-10 23:58 UTC, jwitford
no flags Details | Diff

Description jwitford 2001-01-10 22:50:00 UTC
xinetd fails to correctly set the REMOTE_HOST environment variable.

Although there is a setenv("REMOTE_HOST",..) the code has
presumeably been upgraded to support the "env" and
and "passenv" configuration settings.
Consequently xinetd's environment is not the appropriate
place to add the REMOTE_HOST environment variable.

Comment 1 jwitford 2001-01-10 22:51:56 UTC
Created attachment 7404 [details]
xinetd patch for REMOTE_HOST environment variable

Comment 2 jwitford 2001-01-10 23:58:11 UTC
Created attachment 7405 [details]
xinetd patch for REMOTE_HOST environment variable

Comment 3 jwitford 2001-01-11 00:04:51 UTC
My earlier patch was faulty because of unforseen changes in pre11 which
affected the connection client address.

Unfortunately the latest changes in connection.c also deny client
programs access to REMOTE_HOST if xinetd waits.



Comment 4 Trond Eivind Glomsrxd 2001-01-11 19:21:22 UTC
In which cases would that be a problem?

Comment 5 jwitford 2001-01-11 21:34:31 UTC
Any servers that have "wait = yes" and which need to know the
client IP address need to have REMOTE_HOST set in their environment.
For instance, a shell script, because it cannot do the equivalent of
getpeername() on file descriptor 0.




Comment 6 Trond Eivind Glomsrxd 2001-01-15 17:53:21 UTC
Do you have a specific example I can use for testing, verifying fix etc?

Comment 7 jwitford 2001-01-16 08:36:56 UTC
After considerable thought and effort I have been able to
create an innocuous example for you.

#! /bin/sh
traceroute -n $REMOTE_HOST >>log 2>&1





Comment 8 Trond Eivind Glomsrxd 2001-02-06 23:02:39 UTC
Could you try the xinetd-2.1.8.9pre14-5 RPMS you can find at
http://people.redhat.com/teg/ and see if they solve the problem?

Comment 9 Trond Eivind Glomsrxd 2001-02-13 01:16:04 UTC
This works with xinetd-2.1.8.9pre14-5, possibly earlier ones as well.


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