Bug 2318 - rexec(3) and in.rexecd implement different protocols.
rexec(3) and in.rexecd implement different protocols.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: rsh (Show other bugs)
5.2
All Linux
medium Severity high
: ---
: ---
Assigned To: Nalin Dahyabhai
:
: 2909 3093 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-04-21 15:42 EDT by ange
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-05-19 12:19:24 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 ange 1999-04-21 15:42:31 EDT
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@hplb.hpl.hp.com --
Comment 1 Jeff Johnson 1999-04-21 16:28:59 EDT
*** This bug has been marked as a duplicate of 1696 ***
Comment 2 Jeff Johnson 1999-05-18 12:31:59 EDT
*** Bug 2909 has been marked as a duplicate of this bug. ***

It seems that in.rexecd is buggy and hangs, it can
be reproduced on a base Red Hat 6.0 box with a simple
	rexec -l user -p pass localhost date

Doing an strace on it, we see that the rexec client sends
the port number as the first "argument":
   write(3, "1716\0", 5)                   = 5
and waits for the socket to be created
   accept(4,  <unfinished ...>
while the rexec daemon reads the second argument (user)
*before* creating the socket...

------- Additional Comments From jbj@redhat.com  05/18/99 12:26 -------
As a workaround, add -a to the rexec command line.

------- Additional Comments From jbj@redhat.com  05/18/99 12:27 -------
As a workaround, add -a to the rexec command line.
Comment 3 lionel.cons 1999-05-19 02:48:59 EDT
The workaround sent (-a) doesn't seem to work
for me:
# rexec -a -l root -p rootpass mybox date
mybox.cern.ch: Success
rexec: Error in rexec system call: Success
Comment 4 Jeff Johnson 1999-05-19 12:19:59 EDT
Fixed in.rexecd to repair damage to the rexec protocol when the
last argument to rexec is supplied. The port is sent to the server
which then connects back to the client after which the client
supplies user, password, and command. This is the behavior implemented
on Solaris (by trial) and on FreeBSD (by examining sources). OpenBSD
has an rexecd that is broke the same way that netkit was broke.
Comment 5 Jeff Johnson 1999-05-27 11:53:59 EDT
*** Bug 3093 has been marked as a duplicate of this bug. ***

Redhat is apparently not using the latest netkit. The latest
netkit includes a patch that I contributed that fixes
rexecd.

As soon as I figure out how to submit that patch, I will
send it to you.

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