Bug 1696
| Summary: | rexec pam config incompatible with rexecd as shipped | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | s.ballestrero |
| Component: | rsh | Assignee: | Nalin Dahyabhai <nalin> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.2 | CC: | ange, nwilson, s.ballestrero |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 1999-03-27 00:39:33 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
s.ballestrero
1999-03-23 18:49:15 UTC
*** Bug 332 has been marked as a duplicate of this bug. *** he in.rexecd doesn't behave as the man page indicates. The man page says that the server first reads in a number up to a NUL and then connects back to the client on that socket for the error stream. I ran in.rexecd under strace and verified that in fact after the server reads in the port number it sits there trying to read more data rather than connecting the socket. Here's the relevant excerpt from the system trace: dup2(0, 0) = 0 dup2(0, 1) = 1 dup2(0, 2) = 2 alarm(60) = 0 read(0, "6", 1) = 1 read(0, "5", 1) = 1 read(0, "4", 1) = 1 read(0, "7", 1) = 1 read(0, "1", 1) = 1 read(0, "\0", 1) = 1 alarm(0) = 60 read(0, 0xbffddbaf, 1) = ? ERESTARTSYS (To be restarted) --- SIGTERM (Terminated) --- +++ killed by SIGTERM +++ The SIGTERM was from me killing the process. From the alarm (0) you can see that the process is just going to sit there trying to read. As I said, the man page indicates that the server is supposed to immediately create a connection back to the client at the port specified. Because of this, rexec doesn't work. ‰ The pam secure tty problem has been fixed (see bug #60). The other problem is conceptual. The reverse error connection is not attempted until after the client has sent the port, user, password, and command. After authenticating, then rexecd will attempt to connect back on that port no. The incorrect line in the man page is "... second connection is then created ..." which should be something like "... second connection will be created (after receiving the user, password, and command to run and authenticating the incoming request) ..." I have corrected rexecd.8. I've also added the rexec client per your suggestion. Thanks! *** Bug 2318 has been marked as a duplicate of this bug. *** Firstly, in.rexec in RedHat 5.2 seems to have problems with the pam securetty entry. If you change auth required to auth sufficient, then there is a chance of in.rexec not failing. However... the real reason for this bug report is: If the final argument to rexec(3) is set to 0, then the rexec library call, and the corresponding in.rexec demon work apprently OK. If the final argument to rexec(3) is given as a pointer to a socket descriptor, in.rexec hangs and never logs in... it seems to be waiting for more data for somewhere. Help please! -- ange.hp.com -- |