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.
Created attachment 7404 [details] xinetd patch for REMOTE_HOST environment variable
Created attachment 7405 [details] xinetd patch for REMOTE_HOST environment variable
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.
In which cases would that be a problem?
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.
Do you have a specific example I can use for testing, verifying fix etc?
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
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?
This works with xinetd-2.1.8.9pre14-5, possibly earlier ones as well.