Bug 141293 - Intermittent rlogin failures
Summary: Intermittent rlogin failures
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rsh
Version: 3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Karel Zak
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-30 05:33 UTC by Terry Griffin
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-05-05 20:13:45 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Client-side strace of a successful rlogin (13.76 KB, text/plain)
2004-12-03 05:46 UTC, Terry Griffin
no flags Details
Client-side strace of a failed rlogin. (13.33 KB, text/plain)
2004-12-03 05:48 UTC, Terry Griffin
no flags Details
sucessful client side trace (15.58 KB, text/plain)
2004-12-12 02:06 UTC, Mike Poublon
no flags Details
un-sucessful client side trace (13.97 KB, text/plain)
2004-12-12 02:07 UTC, Mike Poublon
no flags Details

Description Terry Griffin 2004-11-30 05:33:33 UTC
Description of problem:

I'm getting intermittent failure when trying to login in
to an FC3 box using rlogin. All the client side gets is
a "connection closed" message. There are no errors logged
on the server side.

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

rsh-server-0.17-23

How reproducible:

Easy but not 100%.

Steps to Reproduce:
1. Install rsh-server.
2. Enable rlogin in /etc/xinetd.d/rlogin and restart xinetd.
3. In a user account on the server set up a ~/.rhosts file for
   password-free login from some other host.
4. From that other host repeatedly try to rlogin to the server.
  
Actual results:

Sometimes it will work. Sometimes it will fail with a "connection
closed" message. Sometimes it will work but take unusually long
time (several seconds) to complete the connection.

Expected results:

Successful connection every time.

Additional info:

I don't know if it's related or not, but after a successful login
this error is written to /var/log/secure on the server side upon
logging back out:

Nov 28 18:50:36 chinook login: Warning!  Could not relabel /dev/pts/2
with user_u:object_r:devpts_t, not relabeling.

Comment 1 Karel Zak 2004-12-02 16:53:42 UTC
1/ Dont't forget if you call "rsh" without command it uses "rlogin".
It   means in this case you need to enabled "rlogin" in the
/etc/xinetd.d/rlogin too. For testing is good use something like:
"/usr/bin/rsh <host> ls".

2/ You need to add "rsh", "rlogin" to /etc/securetty too.

3/ Must be possible connect from server to client. The rsh/rlogin uses
reverse (stderr) connection. So there is two(!) connections,
client->server and server->client. Maybe you can try disable iptables
(service iptables stop) for your tests.

4/ Your server must be enable convert client IP to full client hostname.

5/ in the file ~/.rhosts is required full client hostname.

If you have still a problem connect to your server, please add to your
bugreport "strace" outputs:

Client: 
        $ strace -f -o client.trace /usr/bin/rsh <host>

Server (it's more dificult):

- create shell script:
     #!/bin/bash
     /usr/bin/strace -f -o /tmp/server.trace /usr/sbin/in.rshd

- add path to this script to /etc/xinetd.d/rsh (options server=)
- restart xinetd (service xinietd restart)
- check the file /tmp/server.trace on server after failed connection



Comment 2 Karel Zak 2004-12-02 17:14:44 UTC
Note: with strace on client you can have a permission problem as
non-root user.

Comment 3 Terry Griffin 2004-12-03 05:44:56 UTC
None of ideas #1 through #5 would explain the intermittent nature
of the problem. When I say intermittent I really mean it. One
second it will work. A few seconds later it will fail. A few seconds
later it might work again. That's not a problem with my system
configuration.

I'm attaching two client-side strace output files. One shows a 
successful rlogin and the other a failure. In the successful case
you can see where it makes the connection, reads "exit\n" as I type
it in at the remote shell prompt, and the session is closed normally.

In the failure case you can see that the connection is initially
successful but at the point where the remote shell (bash) tries
to read a command from stdin it gets an ERESTARTSYS error code and
the session is terminated. This is wrong. It's as though the
ERESTARTSYS error code is being treated as a real error instead of
a request to restart the system call.


Comment 4 Terry Griffin 2004-12-03 05:46:37 UTC
Created attachment 107819 [details]
Client-side strace of a successful rlogin

Comment 5 Terry Griffin 2004-12-03 05:48:36 UTC
Created attachment 107820 [details]
Client-side strace of a failed rlogin.

Comment 6 Karel Zak 2004-12-03 10:33:41 UTC
Thanks for your strace outputs. You didn't use "-f", so in your strace
output missing client child process that read data from server (client
uses two processes).

Please, can you do it again and for server too. And --please-- use
"-f" option for strace :-) I don't see problem in your actual strace
output, but we don't know why client child process was exited.

ERESTARTSYS is only ptrace information about kernel internal stuff and
it doesn't return to userspace. It's no problem.

Please, check your server PAM setting. The "rlogin" use it and for
example pam_limits setting can disable login to server if there is
used all user's resources.



Comment 7 Mike Poublon 2004-12-11 23:16:11 UTC
I am also having this problem. It did not appear to happen until 
after I updated all of the packages on the system. Booting into the 
stock kernel seems to solve the problem for now. I have used the same 
configuration successfully on a RH9 system. 

Comment 8 Mike Poublon 2004-12-12 02:05:43 UTC
Thought I'd add that the error only happens once in a while, and I 
can't seem to tie it down to any particular happening. I executed the 
same command twice within seconds of each other and one failed and 
one was successful. I happened to be strace'ing the execution (as 
shown above with the -f) and will be attaching them.

Comment 9 Mike Poublon 2004-12-12 02:06:56 UTC
Created attachment 108391 [details]
sucessful client side trace

Comment 10 Mike Poublon 2004-12-12 02:07:41 UTC
Created attachment 108392 [details]
un-sucessful client side trace

Comment 11 Karel Zak 2004-12-13 09:30:02 UTC
Make, can you try server side (rlogind) strace too. I think client
side looks without problems.

By the way, "rsh" without command, calls "rlogin".

Comment 12 Mike Poublon 2004-12-13 15:38:34 UTC
I'm currently strace'ing the rlogin as shown above and now the 
problem doesn't occur. Is there a possiblity of a timing issue that 
strace is taking care of. The reason that I mention this is that 
rlogin seems a little bit slower than when it isn't running through 
strace on the server. I've tried around 600 rlogins and haven't had a 
problem. Seems kinda wierd to me.

Comment 13 Karel Zak 2004-12-13 16:49:09 UTC
It looks like bug #137808 -- this bug isn't possible detect with
strace or gdb :-( The problem is somewhere around place where the
"login" tries initialize pseudo terminal.

Comment 14 Terry Griffin 2004-12-16 06:19:26 UTC
Too bad some of us aren't authorized to see #137808.


Comment 15 Paul Armor 2005-01-25 22:16:51 UTC
So, has anyone found a solution for this?  I also am interested, and
am also unable to view #137808

Comment 16 Karel Zak 2005-08-30 12:35:47 UTC
Can anyone confirm this bug on actual FC4?

Comment 17 John Thacker 2006-05-05 20:13:45 UTC
Closing due to lack of response.

FC3 is the responsibility of Fedora Legacy now, and this is not
a security issue.  (Indeed, using rlogin rather than ssh is more
of a security issue.)  If this occurs in FC4 or FC5, please reopen.


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